Re: Re: Re: Re: Why breaking can() is acceptable

[tilly]

With your code snippet, if someone has an object of your class (or a class that inherits from your class) and wants to know if you can foo, where it can foo because of your AUTOLOAD, then your can will say that it can't foo because the person calling can is not making that call from within your class.

Again, this is not as easy as it looks.

Furthermore allow me to point out that AUTOLOAD predates can by many years, and is far more widely used. Is code that was written before they decided to start populating UNIVERSAL:: in Perl 5.004 broken because Perl 5.004 came out? Does code written by someone familiar with Camel ed. 2 need to be rethunk because p5p decided that people might like to have a feature that most people don't use?

My belief is that p5p adding to Perl should not invalidate accepted practices. My further belief is that of AUTOLOAD and can, AUTOLOAD matters more to most Perl developers. Going further, my impression is that people who are familiar with other dynamic languages are more likely to want to reach for something like AUTOLOAD (perhaps they'll call it method_missing, but they expect it to be there) than they will can.

My conclusion, therefore, is that someone who wants developers to not break can with AUTOLOAD is fighting an uphill battle. Furthermore, knowing everything that I do, my sympathies are with the person who wants to use AUTOLOAD to full effect. (Though admittedly I'm more likely to creating a bunch of functions by typeglobbing some closures rather than use AUTOLOAD. Unless I have a reason to use AUTOLOAD.)