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
-~----------~----~----~----~------~----~------~--~---
