--------------enigC945C8CDC6AFA8147C2F82B6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

dblack / wobblini.net wrote:
> Hi --
> 
> On Sun, 5 Nov 2006, David Vallner wrote:
> 
>> Hmm. This might have been brought up before, but blocks seem rather
>> underpowered with respects to manipulating them? A way to prevent their
>> binding scope from being clobbered by using them in an instance_eval
>> context would be nifty.
> 
> But instance_eval takes a block; it's not a special context, but just
> how the method works.  I don't think it would be good to try to figure
> out where the block came from and set up some mechanism that way.
> That goes against the grain of having first-class closures at all.
> 

My point is that with instance_eval, the block doesn't close over its
lexical scope as is most often expected, but over the instance scope of
another object. At least it seems that way to me. It might be useful,
but it's an inconsistency that a library can force on its client. The
whole proposal at first was a longshot, and sort of a workaround against
flaky API design.

> I think one just has to hope people won't do the "stealth"
> instance_eval.  If they do, you'd presumably know about it from the
> docs, and can avoid it.
> 

Which is why I'd prefer that libraries don't do this at all in their
API. It seems like a code / design smell to me to make part of your
object internals part of your API, and there are less iffy ways of
exposing part of your object conditionally - e.g. dynamically defining
extra singleton accessors for the attributes you want the block to have
access to before yielding the object to the block as a regular parameter
and undefining them afterwards. And in the RMagick example, I have
slight doubts that for any and all practical reasons and purposes,
having the Image::Info object as a block parameter to Image#write
instead of using instance_eval would be any different except that it
would surprise users less.

David Vallner


--------------enigC945C8CDC6AFA8147C2F82B6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFTgqpy6MhrS8astoRAtgkAJ99bfl9965S/v8mpkDKxbbWxKIbeACdGdMV
MnHYNZ2p3qoJLYusHc+zRWEJm
-----END PGP SIGNATURE-----

--------------enigC945C8CDC6AFA8147C2F82B6--