Re: Re: Re: Symbol table globbing from object refs

[diotalevi]

->can() doesn't handle AUTOLOADed methods, FYI.

[broquaint]

It can if you're using the UNIVERSAL::canAUTOLOAD module.

[diotalevi]

What is that, a joke? `cd src/perl-5.8.2; grep -ril canautoload` doesn't show any such thing.

[Limbic~Region]

diotalevi,
What is that, a joke?
The answer appears to be yes and no. A new module uploaded 10 Nov 03. From the docs:

Ever flying in the face of common sense, this module makes a special effort to make a section of "can" in UNIVERSAL false.

Cheers - L~R

[chromatic]

It does if you tell it to, which you should.

[tilly]

Why should you tell it to?

When I write an AUTOLOAD method, I'll typically dynamically decide at runtime whether or not I really want to handle it. Anyone who assumes that I'll handle their method because I have an AUTOLOAD is more often wrong than right.

Unless we coordinate on how to declare methods, there is no good answer to that.

Furthermore I am uncomfortable with encouraging people to roll their own can because when I use it, I darned well expect it to work right and they might get it wrong. Do they handle multiple inheritance properly? Do they return a subroutine that can be called directly? (Returning the AUTOLOAD won't work.) Do they return the same subroutine multiple times for the same class?

Yes, I have written code which would break if you change any of the above properties.

Anyone who cannot be trusted to think of all of this shouldn't be overwriting globally defined methods which could be called by other people who expect that things work properly.

[chromatic]

This discussion might be worth promoting to a root note, since there's a lot of philosophy involved.

I believe that you should override can when you provide an AUTOLOAD so that the normal Perl mechanisms work appropriately. I want to be able to ask "does this package or class or object have a subroutine or method of this name"?

Not providing can means I might get the wrong answer.

I'm not convinced by the point that you want to decide this at runtime — your can can use the same behavior as your AUTOLOAD. The same goes for returning the correct code reference. If you can get it right in one spot, you can get it right in another.

I also think that any programmer smart or experienced enough to get AUTOLOAD right is capable of getting can right. You're right that it can be tricky, but can is also documented.

If people get it wrong, well, people get all sorts of things wrong. That doesn't mean that no one should do those things.

[diotalevi]

Did that change since 5.8.0?

[chromatic]

No, you still have to write your own can method. It's very hard to do this automatically.

[nothingmuch]

Well, if it we're a means of getting responses for methods you don't know of it would be nice - most people that go around breaking it simply implement their own (see Class::Classless - i just submitted a patch (phew, a whole one line) for it to return code refs instead of 1, and Class::Object - i trust the documentation).

The problem is that @ISA is not used, or perl's builtin method calling system is extended. That's the showstopper.

Provided Autoload would provide (and export) a can, which either returns an anonymous subroutine that takes care of things, or actually loads the sub and returns a subroutine ref to that, It should pose no problem at all.

[tilly]

I hope that your one-line patch to Class::Classless addressed the documented reason for originally not returning code refs, and fixed the documentation as well.

[nothingmuch]

For the (curios|record), I believe, after checking repeatedly, that the patch is still valid. Please review it and comment on it if applicable, on the cpan requests tracker.

Thanks!