I think you're going to get into really scary metaprogramming land if you
embark on efforts to rearrange precedence and the like.
The goal for Sugar Glider is to provide a block based syntax which is
recognizable given the current syntax and has better semantic indicators but
exposes the logical operators that one would want to do complex querying:
Human.all(:last_name=>"Obama", :first_name=>"Barack")
becomes
Human.all{ last_name == "Obama"; first_name == "Barack"}
or if you wanted to use regexp matching
Human.all{ last_name =~ /Obama/; first_name =~ /Barack/}
Human.any{ sex == "F"; all{ last_name == "Bush"; dob < "1933-12-31" } } #
any woman, or a bush born after 1933
Given the fact that the matchers (in this case all named from properties)
are just objects that receive statements, they dont' care whether you've
mashed them together with semicolons or other connectives, so you could also
say the following if it makes you feel better:
Human.any{ sex == "F" or all{ last_name == "Bush" and dob < "1933-12-31" } }
Sugar Glider as it stands does do some dynamic generation of classes, and
extends a bunch of the internals of DM (in particular, belongs_to, has,
property, and the #all methods on Model and Collection), but the execution
is designed to be very straightforward. Sugar Glider is currently backwards
compatible as well, since tacking on a block syntax doesn't interfere w/
ones ability to accept hash based queries, so the following are all
equivalent:
Human.all(:last_name => "Obama", :first_name => /a/)
Human.all(:last_name => "Obama"){ first_name =~ /a/}
Human.all{ last_name == "Obama"; first_name =~ /a/}
Anyway that's what i've thought of so far. Are there other things that
people would want to see?
-Ted
On Sat, Mar 20, 2010 at 10:37 PM, trans <[email protected]> wrote:
>
>
> On Mar 19, 3:15 pm, Calamitas <[email protected]> wrote:
> > Hey Tom,
>
> > The problem with this syntax, and to me the major problem with this
> > technique, is illustrated by the fact that the example as you've shown
> > here doesn't work. The & operator actually has the wrong precedence
> > for this to work and you have to write this:
> >
> > Song.select do |s|
> > (s.artist =~ /Mary/) & (s.year > '1980')
> > end
> >
> > You could say that this is more readable and good practice etc., but
> > in the end it is just plain annoying and easy to forget. Also, having
> > to use &, | and ~ instead of &&, || and ! is a big enough problem as
> > you'll have a tendency to write the actual boolean operators and doing
> > so can lead to weird bugs.
>
> Ah, right. But what's the trade-off? It's either that or a less
> intuitive syntax or a great deal more overhead.
>
> What we really need is a way to control precedence.
>
> > I've actually considered a version that is a lot smarter and can work
> > with &&, || and !, but I've never gotten around to implementing it.
> > The idea was to treat the block as a black box and determine its
> > behavior by feeding it different inputs and registering the output.
> > Karnaugh maps would then allow you to find a matching expression. In
> > the above example with 2 inputs (s.artist and s.year) you'd have to
> > test just 4 combinations, but in general with n inputs you need to
> > test 2**n combinations, so in practice it can be impractical. Plus it
> > will never be perfectly general, and it cannot handle closures.
> >
> > Nevertheless, I would be interested in seeing this implemented to see
> > how usable it is in practice. If you are interested in giving it a
> > try, I'll see if I can get the presentation back online because we
> > moved our servers to a different hosting company and the link is now
> > broken. You can always make it an extension to DataMapper without the
> > need for it to be in the official distribution; it can just translate
> > to regular DataMapper syntax.
>
> Yes, please. I would be more than happy to see the presentation again
> and translate the code into a DataMapper extension. Despite precedence
> issues it would still be more intuitive than any of the other
> solutions I've seen.
>
> Trans
>
> --
> You received this message because you are subscribed to the Google Groups
> "DataMapper" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<datamapper%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/datamapper?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en.
