Re: Using SUPER in dynamically generated subs

The problem with this, is that SUPER refers to the @ISA of the class it is COMPILED into, not the class of $self at runtime.

I'm not sure why you think this is "a problem".

This is the only sensible way for it to work.

You don't want to find the same named method in the superclasses of the object. You must find the same named method in the superclasses of the class in which you are compiled.

Consider X @ISA Y @ISA Z. Now, call method doit on an X, which isn't found, so we go up to class Y. In Y::doit, we want to call SUPER::doit. We cannot look at the @ISA of the object (which is an X), because that'll come right back around to us again! We must look in the @ISA of the class to which we belong (in this case, Y::doit), yielding a potential call to Z::doit.

So, if I'm following what you're trying to do, you'll be making classes that cannot be subclassed properly, because they'll be looking at the class of the object to get parents, not the "class" of the method. Broken.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on Re: Using SUPER in dynamically generated subs

Replies are listed 'Best First'.
Re^2: Using SUPER in dynamically generated subs by chromatic (Archbishop) on Nov 14, 2006 at 03:56 UTC
I'm not sure why you think this is "a problem". This is the only sensible way for it to work. Was that sarcasm? The current algorithm has some bizarre fetish for static code, which is a bit odd to encounter in a dynamic language with late binding everywhere else. It makes calling the parent method from methods defined in roles very difficult, for example. A working algorithm would search for a possible parent method in the list of MRO candidates after the current point of call. Note that this is sort of pretty much exactly like SUPER does.	[reply]
Re^2: Using SUPER in dynamically generated subs by clinton (Priest) on Nov 14, 2006 at 10:33 UTC
The problem is that I want to dynamically generate a sub that would APPEAR to have been compiled into package X (and so inherit package X's `@ISA`), even though it was actually generated in package Y. But my anonymous sub also relied on the state of the variable `$alias_for` at compile time. And when I tried a string-eval on the sub, it complained that `$alias_for` would not stay shared, ie you can have your cake or eat it, not both... Thanks to ikegami for showing me how to have both.	[reply] [d/l] [select]