From: Robert Klemme <bob.news@...>
Date: 2003-12-10T03:42:01+09:00
Subject: Re: Adjusting the Scope of Blocks


"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0312090906230.13718-100000@wobblini.net...
> 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.

Yeah, it *is* hybrid.

> > 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 :-)

Of course you are. :-))

/me is rolling his eyes and moving his hands in spooky ways
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
You like hybrid concepts.
....

Feel better now?  ;-)

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

Not exactly, it overrides any setting of self in the environment that
cometh with the block / closure.  IOW, the closure's env is modified for
this call so that "self" points to the invoking "self" and not the "self"
at the time of definition.  So it is not really a noop.

Kind regards

    robert