From: Piers Cawley Date: 2001-08-12T17:02:07+09:00 Subject: [ruby-talk:19585] Re: Perl/Python/Ruby common backend (Parrot, can Ruby play too?) "David Simmons" writes: > "Ned Konz" wrote in message > news:Mvbc7.54318$WD1.3252627@e420r-atl2.usenetserver.com... > > On Wednesday 08 August 2001 12:20 am, Piers Cawley wrote: > > > Ned Konz writes: > > >> Calling, say, $self->SUPER::method merely skips the > > > > current class (and only works if written in the namespace (package) > > > > of the class that's being defined, not dynamically as I've wanted it > > > > to). > > > > > > Don't get me started on this. See the debate on the subject I had with > > > perl5porters about a month back. And which, having looked up the > > > SmallTalk way of doing it, I may be returning too. > > > > > > Annoyingly, there seems to be no way of implementing a reliable > > > SUPER.pm which will do the right 'dynamic' thing, because perl doesn't > > > cache the appropriate information when it makes the function call. > > > > In Class::Prototyped we ended up having to use closures to get "proper" > super > > behavior dynamically. > > Hmm. Being a Smalltalk implementor for the last decade or so... > > The smalltalk semantics for "super" are to "lookup" a method implementation > by starting the message lookup from the "superclass" of the > method-dictionary (class) in which the super/calling (method with the code > using super) message is invoked. [...] > So, a super lookup of a scoped message will do the right thing, even if the > object is managed (delegated behavior/proxy etc). Cool. The problem with the current perl implementation is that it starts its lookup in the superclass of the class in which the invoking method was *compiled*, which is often nowhere near where it was *found*. And perl doesn't hang on to information about where it was found, so attempting to write a, say, HYPER.pm that does the Right Thing is next to impossible... -- Piers Cawley www.iterative-software.com