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


"Dan Doel" <djd15@po.cwru.edu> schrieb im Newsbeitrag
news:3FD5F0F8.3030500@po.cwru.edu...
>
> >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.

Well, is a special kind of closure; a closure that allows through internal
magic that self is temporarily bound to something other than at creation
time (dunny a term for this though).  From a theoretical point of view it
might be spooky, but it comes in handy from time to time if you need to
invoke several methods of an instance.

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

.... or in another context when doing "eval( code, binding )"

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

Nicely put.

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

Good idea! +1  I was missing exactly that feature the other day. :-)

Kind regards

    robert