From: "David A. Black" <dblack@...>
Date: 2003-12-10T02:29:35+09:00
Subject: Re: Adjusting the Scope of Blocks

Hi --

On Wed, 10 Dec 2003, Dan Doel wrote:

> 
> >I had never noticed that closures behave this way when
> >instance_eval'd.  My initial reaction is dislike.  To me it feels too
> >close to having the code in the block interpreted as an eval string.
> >
> >...
> >
> >
> >It feels non-closure-like to me.  I don't see why a block should care
> >what 'self' is at the time it's called; I thought the point was for it
> >to preserve the context of its creation.  
> >  
> >
> 
> Essentially it's not exactly a closure at that point.  But that's not 
> necessarily bad.
> 
> After all, the point of any #eval or variation thereof is to execute the 
> given code in the
> current context (where context might be scope, or merely with the 
> current self).

This concept of "context", though, seems like a bit of a retro-fit;
after all, scope (as reflected in, say, visibility of local variables)
and setting of self (i.e., what's the default receiver) vary
independently and don't necessarily fall easily under one master term.
I think that's what bothers me about this: it strikes me as a hybrid,
ad hoc way to achieve something that is neither really a closure nor
(in my opinion) really in keeping with the usual behavior and purpose
of #instance_eval.

> In other words, there's two ways to look at Proc objects.  If you're 
> using #call, a
> Proc is a closure.  If you're using ?_eval a Proc is more along the 
> lines of "just a
> section of code."

That's what I don't like.  (I'm not sure if that means I am purist or
just ignorant of some hybrid computer science concept which makes
sense of this :-)  Actually I feel that "self.instance_eval" should be
a no-op, since what it conveys (absent the magic) is: execute what
follows, setting self to what it already is.  

> This is the main reason I brought up dynamic scoping and an #eval that 
> accepts
> Proc object to execute a few days ago.  To me it seems more elegant to 
> pass a
> "code section object" to #eval than it does to pass a String, and it 
> isn't that
> inconsistant with what's already in place.

I may have passed over that thread... I'll look again.  


David

-- 
David A. Black
dblack@wobblini.net