From: David Vallner <david@...>
Date: 2006-11-05T21:18:20+09:00
Subject: Re: Accessing instance vars in a block?

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

Ezra Zygmuntowicz wrote:
>=20
> On Nov 4, 2006, at 11:24 AM, Joe Ruby MUDCRAP-CE wrote:
>=20
>> I'm using rmagick:
>>
>>   img.write(self.path) { self.quality =3D @quality }
>>
>> @quality is nil inside the block.=20
>=20
>     It looks like maybe ImageMagick is using instance_eval inside that
> block. This is why the @instance vars don't work inside of there. The
> ugly workaround is to use local variables:
>=20
> quality =3D @quality
>  img.write(self.path) { self.quality =3D quality }
>=20

<mad-rant>

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. Or having nested block bindings depending on use
- so if this block got instance_eval'ed twice inside RMagick, it would
look up read variable references in all the scopes that apply, last
object first. With the interpreter looking for and reporting possible
conflicts as a warning when those are allowed (not otherwise, that
sounds like a horrid performance hit without any sort of code path
inference to optimize the detection process.) Of course, this might
still be a problem with autovivification of instance variables

</mad-rant>

Of course, this would probably do Cruel and Unusual Things (tm) to block
performance, and it's possible to mitigate the problem by always
documenting what methods rescope their block argument, and then users
actually reading the documentation.
(http://www.simplesystems.org/RMagick/doc/image3.html#write does state
the block sets attributes on another object.)

Of course, that necessitates still the Javascripty hack of reassigning
stuff to instance variables - personally I think instance_eval'ing an
external block is a hideous practice that violates encapsulation with
gay abandon, and therefore shouldn't -ever- be used across the library /
client boundary. In this case, I'd go the way of yielding the
Image::Info object to the block, even if that robs you of the novel and
exciting feeling of having direct access to a library's unmentionables
as the common case instead of the special one.

David Vallner


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

iD8DBQFFTdZ1y6MhrS8astoRApeGAJ92DvTOUOqgRIJUmywwyiFD2ThNVQCbBKIK
iY34wSUwccYjGp73sHWTKcc=
=cXCd
-----END PGP SIGNATURE-----

--------------enigAD0F3593FE5FC3ACA2DF3B9D--