On Fri, Jul 22, 2005 at 12:53:45AM -0700, Brent 'Dax' Royal-Gordon wrote: : Larry Wall <[EMAIL PROTECTED]> wrote: : > $x is visible only in the rest of the lexical scope. In contrast, : > $_y would presumably still be visible if the class were reopened. : : This strikes me as an exceedingly bad idea. : : Encapsulation is a very good thing, and I'm glad it's being added to : Perl 6. But once in a while, you really *do* need to break : encapsulation. Maybe a shortsighted module author didn't add an : accessor you need, or maybe you're doing something highly magical for : (e.g.) debugging. In any case, though, you'll need an escape hatch, : and I really think extending a class should be it. By extending a : class, you're explicitly saying "I'm going to butt into your affairs"; : at this point, if you're not sure what you're doing, you're probably : going to mess things up *anyway*.
With sufficient work it will almost certainly be possible to excavate the lexical scope of the class and get back to the $x proxy somehow. We are under no obligation to make that easy, however. : Also note how subtle this point is (it's about the only point I didn't : get from the original message); the degree to which it requires the : class's programmer to predict how others might want to extend his : class; and the syntactic kludge required to specify it (namely, the : sometimes-magical underscore). I really think this is a very fine : distinction, which programmers will get wrong half the time, and which : you don't even have enough syntax to cope with *anyway*. It's almost certainly the case that ordinary programs will ignore the $_x option in most cases. The default submethods will manage $_x as the "backing store" for $.x transparently. Only if you want to write your own BUILD or want to "trust" other classes will you have to deal much with the $_x form, and neither of those are exactly newbie pursuits. In any event, the fact that reopened class scopes can see $_x is just sort of an accident of being associated with $.x, since the $.x name (or at least the .x name) has to be stored in the class's package. Even reopened classes should probably prefer $.x over $_x except in those cases where explicit de-virtualization is necessary. But as usual, I'm seeing these issues sideways to everyone else, which means I could certainly be blind to something that's obvious to others. Hmm, would it help if the devirtualized form were $._x instead of $_x? Perhaps that shows the relationship better. (It would still imply that _x is the corresponding private method, of course). But it would further discourage people from by default declaring all their private variables as $._foo, which is probably a good thing. It would also make _ no longer a kind of pseudo-twigil, and create a symmetry between $._foo and $obj._foo. Then then . twigil is *the* mark of a self-call. Larry
