James Edward G. II wrote:
Our current pattern is:
constrain function(…).predicate(…)
First of all, can’t function() always return the needed proxy object,
without an need to wrap? Or is the issue when we don’t use the function()?
Yes, wrapping was to use
constrain variable.relation(arguments)
consistently for everything (the examples for that are under the header
“Proxy objects”).
Translating the examples I come up with:
constrain_relationship x, :>, y
The symbol could be replaced with the other logical comparisons as needed.
For things like sorted(), I’m wondering if we could add that as an option:
constrain_equal enum, other_enum, :sorted => true
What do we think about this direction, on the whole?
I have added that syntax to the examples to get a feel for it:
http://gecoder.lokorin.org/dev/wiki/Syntax_test#constrain_.2A_arguments
It’s a bit bulkier at times, but is probably more conventional (possibly
easier to get to grips with?). My primary concern with it is probably
things like sort constraints where it isn’t necessarily immediately
clear which of the enumerables that will be sorted (i.e. it forces one
to look into the API documentation). Those constraints can probably be
eliminated/mitigated with some other choice of words or option names
though. I will see what it leads to.
On Jun 7, 2007, at 10:07 AM, Andreas L. wrote:
I have added that syntax to the examples to get a feel for it:
http://gecoder.lokorin.org/dev/wiki/Syntax_test#constrain_.
2A_arguments
It’s a bit bulkier at times, but is probably more conventional
(possibly
easier to get to grips with?).
I agree that it lacks the sex appeal of the RSpec approach. However,
it does allow us to avoid wrapping all variables and core class
hacking, which I consider big wins. I would be willing to pay the
price.
James Edward G. II
James Edward G. II wrote:
which I consider big wins. I would be willing to pay the price.
I’m not really sure that the cost compared to the others is that much
lower. The following are the changes necessary to make the others work
as far as I’m aware, please correct me if I’m missing something.
- Custom enums with variables have to be wrapped before use (arrays and
matrices created through the convenience methods are wrapped there).
- It becomes harder to create temporary arrays of variables, e.g. [x,y].
Instead the user has to use variable([x,y]) or something similar (or
possibly IntVar.array(x,y) if that’s better).
Beyond that I can not see anything that requires wrapping or altering
core classes (or any other non-gecode classes for that matter).
What I see as a bigger problem of must/must_not is where to fit the
constraint options. It might be necessary to change it around a bit to
variable.<must|must_not> relation(argument)
or something similar for that to work.
On Jun 8, 2007, at 3:18 AM, Andreas L. wrote:
- Custom enums with variables have to be wrapped before use (arrays
and
matrices created through the convenience methods are wrapped there).
- It becomes harder to create temporary arrays of variables, e.g.
[x,y].
Instead the user has to use variable([x,y]) or something similar (or
possibly IntVar.array(x,y) if that’s better).
Beyond that I can not see anything that requires wrapping or altering
core classes (or any other non-gecode classes for that matter).
You are probably right.
If we go with the wrapping approach, I just think the most important
thing is to make sure we are careful to support custom data
structures as painlessly as possible.
James Edward G. II