chromatic wrote:
> I don't think the bug is in method resolution. I don't
think the bug is in
> can(). I also don't think there's a good general
heuristic that can support
> this behavior while distinguishing between accidentally
taking a reference to
> an undefined invokable symbol that just happens to
share a name with a method
> somewhere in a resolution hierarchy, so I don't think
there's a fix for this
> behavior if it happens not to be a bug in the invokable
object.
There is this minor annoyance that Perl is a *dynamic*
language, so I
can require or use modules _long_ after the reference has
been taken, so
the lazy resolution won't happen until that method is
actually called.
At that point, there is no way of knowing whether the
inherited method
should be called (or in fact which multiply-inherited method
was intended).
How about the instance where I write a subclass,
deliberately break the
inheritance for a method (say it is an expensive full-table
database
search) on the assumption that my code never uses that call,
and any
other code making that call should die (or be forced to use
eval to
catch that behavior).
I'll do you one better - I don't think this is a bug. We
could add a
large warning not to take references to function names
(without testing
for definedness) if you expect OO inheritance to have any
hope of
working, but it isn't something that can be
"fixed", AFAICT and IMNSHO...
John
|