James Edward Gray 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"). > If we want to get rid of the need to wrap, we need to eliminate the > calls on random objects. That's not so bad, because we really want or > constraint builders worrying about the details for us. > > Maybe the issue is that I led us down the wrong path with my RSpec > suggestions. What if we tried something more like Test::Unit's > assertions. I'm now thinking of a pattern like: > > constrain_...(args, hash_style_options) > > Translating the examples I come up with: > > constrain_equal x, y > constrain_not_equal x, y > constrain_in x, enum > constrain_not_in x, enum > constrain_same enum > constrain_distinct enum > > The operators are a little clumsier. We could do constrain_less_than(), > constrain_greater_than(), etc. This might be a better option though: > > 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. -- Andreas Launila