On Mar 1, 8:21 pm, David Lee <[email protected]> wrote:
> Because I thought you were open to breaking backwards-compatibility
> for a nicer DSL, I proposed splitting #filter and #where so that we
> can have both a backwards-compatible method and the newer method.
> However, I think there's a better way.
I am open to breaking backwards compatibility for a nicer DSL, but I
think making #where different from #filter is a step in the wrong
direction.
> I did not know that local variables in the lexical scope were
> available to a block that is instance_eval'd. Now knowing this, I
> think the following behavior for #filter and #where would be best
> (it's even backwards-compatible):
>
> def p
> 1
> end
> n = 'hotdog'
> dataset.filter(self) { (price > p) & (name == n) }
>
> Basically, the block will be instance_eval'd on a VirtualRow and the
> VirtualRow will first proxy any method to the variable passed into
> #filter, and default to your proposed behavior when the argument does
> not have the proxied method defined.
>
> If you don't need to reference any methods, then you can just leave
> out the argument and it will default to your proposed behavior.
It's not backwards compatible. Among other things using instance_eval
always changes the meaning of instance variables inside the block.
Also, filter already accepts arguments along with the block and ANDs
them together. It's actually less backwards compatible than my
method, because to implement your method, you require that self be
passed in, which isn't done now.
The thing I like about my solution is that if gives the user choice
while being simple to understand. If you only need access to local
variables (or don't need access to anything), don't have a block
argument and use the less verbose method of creating identifiers and
functions. If you need access to something other than local
variables, give the block an argument and use the block's argument to
create identifiers and functions, while having methods called without
an explicit receiver go to the self object of the enclosing scope.
Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" 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/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---