On Apr 10, 8:55 pm, David Lee <[EMAIL PROTECTED]> wrote: > > The following is probably old-hat for some, but others might find it > > interesting if not useful: > > >http://www.xaop.com/blog/2007/10/07/video-how-to-create-a-domain-spec... > > I like the DSL that they demonstrate in the link you provided. > > I think we might be able to get something very close to amibition's > syntax using this: > > Post.filter do |posts| > posts.id > 1 > posts.name ~ /hello/ > posts.date > Date.today | posts.date < 50.days.ago > ( posts.size > 50 & posts.size < 100 ) | ( posts.author_id == nil ) > end > > also can be: > > Post.filter {|p| (p.id > 1) & (p.name ~ /hello/) & > (p.date > Date.today | p.date < 50.days.ago) & > ((p.size > 50 & p.size < 100) | (p.author_id == nil))} > > This can all be done without ParseTree. > > However, it's not the symbols-based DSL that sequel uses... > > What do you think, Jeremy?
I like the idea better than the and/or hash method idea. Unfortunately, you won't be able to have that exact syntax because of operator precedence issues. It's going to require parenthesis around most expressions because "&" and "|" have higher precedence than ">" and "<". I'm not sure how much less friendly that makes the syntax, but I don't see an alternative syntax that would be better without ParseTree. Here's what a working example could look like: Post.filter {|p| (p.id > 1) & (p.name =~ /hello/) & ((p.date > Date.today) | (p.date < 50.days.ago)) & (((p.size > 50) & (p.size < 100)) | (p.author_id = nil))} If we wanted to get crazy, we could always instance_eval the block (this requires we change the = to ==): Post.filter {(id > 1) & (name =~ /hello/) & ((date > Date.today) | (date < 50.days.ago)) & (((size > 50) & (size < 100)) | (author_id == nil))} That may be too much magic, as you wouldn't be able to call methods from the surround scope inside the block, you'd have to assign the results of the method to variables before the block. It looks a little bit nicer, but you still have those ugly parentheses. Anyway, I like the general idea. I agree with Aman that it's something that needs to be revisited. We know that relying on ParseTree is not sustainable in the long run, so we have to switch off of it at some point, or be resigned to only running on MRI 1.8. Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to sequel-talk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---