Dan Sugalski wrote:
>
> At 12:06 AM -0500 2/21/03, Benjamin Goldberg wrote:
> >Andy Wardley wrote:
> >>
> >> Dan Sugalski wrote much sense, including these gems:
> >[snip]
> >> > Code must be able to fetch a handle on a particular method for
> >> > later calling
> >>
> >> By this I presume you mean that the handle would be frozen to the
> >> method as it was when then handle was fetched? If you later
> >> re-define the method, the handle would remain pointing at the
> >> original method, not the new one.
> >>
> >> Or not?
> >
> >Redefining methods is almost (but not quite) as evil as altering
> >inheritance trees (at least wrt to it's effect on caching methods).
>
> So? This is perl, it happens with some frequency, and other languages
> we'll be running (like Ruby) do it rather more than perl does.
> Doesn't matter if we like it or not, it's going to happen so we deal
> with it. There are optimization tricks we can use, but they need to
> be behind-the-scenes tricks and not affect language semantics.
I haven't said that we should rule out method redefinition... I am,
however, saying that we should handle it no worse than (and preferably
better than) perl5 does it.
My bit of example code was merely to demonstrate that UNIVERSAL::can()
from perl5 clearly has the problem that Andy Wardley worries about wrt
"freezing" to a particular definition... Thus, it *may* be a good idea
to *not* provide a user-code-level means of obtaining method handles, or
else it will likely have the same problem as perl5's ->can(). In other
words, I'm agreeing with you -- any method-handle-obtaining-for-caching
should be entirely behind the scenes, where we can easily keep track of
whether a cached handle is still valid.
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0 &&
my$__;s ee substr$;,$,&&++$__%$,--,1,qq;;;ee;
$__>2&&&__}$,=22+$;=~y yiy y;__ while$;;print
