AUTOLOAD

[Simon Cozens]

Dirk Koopman:
> >First, there is no such thing as static and non-static methods. There are
> >entries in a hash. That's all.
> 
> Thank you, I know that. 

If you know that these concepts do not exist, it would be wise to stop using
them.

> modules that are in use. Can() will not see as yet undefined methods 
> *unless* someone has arranged, in advance, for that to happen.
> It is in that, narrow, sense that I use the word "reliably". 

So the whole problem you have is that your programs cannot predict the future?
I am glad we have got to the bottom of your confusion. Yes, can() cannot see
the future. But, as chromatic points out, even that can be fixed! 

The problem again is with your expectation. You expect to be able to use can()
 - in a dynamic language - to give you "reliable" information about methods
which do not exist yet but may possibly exist at some point. This is crazy,
for several reasons, chief amongst which is that is not the job of can().

can() tells you what the object can do now. This is why we call it can(),
and not might_possibly(). If you want to implement might_possibly(), feel
free; I think Acme::HaltingProblem might be able to help out there.

Once again this is nothing to do with AUTOLOAD. I honestly don't understand
why you're picking on AUTOLOAD, when it sounds very much like your real gripe
is that you're choosing to program in a dynamic language despite the fact that
you actually don't like the flexibility that dynamic languages give you. Why
pick AUTOLOAD? Methods can be put into a stash in a variety of ways, and
AUTOLOAD is just one of those. 

Saying that AUTOLOAD is bad because it stops can() from predicting the future
is, simply, wrong-headed; a false conclusion based on false premises.

-- 
Look, I was wondering whether the closure of Magdalen Bridge
involved binding all of its free variables...
    - Geraint Jones