On Jan 28, 2009, at 10:50 PM, Dan Kubb (dkubb) wrote:
> > Paul, > >> I'm having trouble designing a way to specify this in the user-facing >> side of it. We've brainstormed a couple examples at [2], but I'm not >> happy with any of them, for various reasons. The all seem verbose >> and/ >> or unintuitive. Thats why I'm coming here for help. Please post any >> bright ideas you might have on how we can make this workable and >> rubyish. > > I forked your gist and added a few at the bottom: > > http://gist.github.com/54421 > > My favorite syntax is still Ambition's, which uses the Ruby Enumerable > API: > > # WHERE name = 'Dan' OR name = 'Paul' > Model.select { |o| o.name == 'Dan' || o.name == 'Paul' } > > # WHERE name = 'Paul' AND ( age < 18 OR age > 21 ) > Model.select { |o| o.name == 'Paul' && (o.age < 18 || o.age > 21) } > > # WHERE NOT name = 'Paul' > Model.select { |o| o.name != 'Paul' } > > The reason I love this syntax so much is because it can be made to > serve a dual purpose. If used on a Collection object that's already > been loaded we can just use the actual block to iterate over the in- > memory objects and return the results. It's so beautifully elegant. > > The downside to this syntax is that it requires ParseTree. As I > understand it ParseTree is now available for JRuby, although it may > not be as stable or have all the features as the one for MRI. I don't > know if there's a version of ParseTree that works with 1.9 either. > We're want to make sure dm-core works at least the latest stable MRI > 1.8.6, 1.8.7, 1.9.1, and JRuby. > > There's also the question of performance. I mean, compared to the IO > time any parsing done on the block will probably be a rounding error, > but it's still something to keep in mind. The impact can be lessened > with some caching too. > > If both of those drawbacks can be resolved I would love to see this be > considered. At the very least there's going to be a dm-ambition > plugin that implements this. I've been talking about doing it for so > long, but if there's someone out there interested in an Ambition > plugin for DataMapper please let me know -- I'd rather have it soon, > than delay a few months while I get dm-core stuff sorted out. Either > way it *will* happen, it's just a matter of when. You guys might want to take a look at some old code of mine: http://github.com/ezmobius/ez-where/tree/master It gets as close to the ambition syntax of just ruby blocks and selectors as you can get in pure ruby without requiring parsetree. You won't be able to use it wholesale as it is tied a tiny bit to AR but there are some good syntax ideas in there and a huge test suite to play with. Cheers- Ezra Zygmuntowicz [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
