--------------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+zRWE Jm -----END PGP SIGNATURE----- --------------enigC945C8CDC6AFA8147C2F82B6--