in reply to Re: Re: Re: Re: Symbol table globbing from object refs
in thread Symbol table globbing from object refs

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.

  • Comment on Re: Re: Re: Re: Re: Symbol table globbing from object refs

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Symbol table globbing from object refs
by chromatic (Archbishop) on Nov 30, 2003 at 18:45 UTC

    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.

[reply]
[d/l]
[select]
      I just realized that I have been misunderstanding your proposal.

      You think that whoever implements an AUTOLOAD should implement a can method in their own class that will indicate whether or not AUTOLOAD in that class will provide a given method, and then allows you to go to the NEXT class if it does not. (The amount of time that Perl went without a proper NEXT implementation is an example of why I don't assume that people will get multiple inheritance right.)

      I thought that you thought that UNIVERSAL::can should be overrided like broquaint suggested so that an AUTOLOAD should be assumed to provide every method. Which is a simply horrible idea.

      I still don't like your approach, but I dislike it less. My reason for disliking it is that you are making it darned easy for duplication of logic to happen, all to improve an (at this point pretty badly) broken assumption that can should see methods provided by AUTOLOAD. Trusting lots of different people to get something right is likely to break. Particularly if it isn't something currently being widely done. As evidenced by docs and current CPAN code. Heck, even core modules like AutoLoader don't think about can.

      And what I don't trust will be done reliably, I prefer not to trust at all no matter how convenient it might be if it actually worked.

      (Of course my tendancy is to write code to install many similar subroutines dynamically rather than lazily do it with AUTOLOAD. Which sidesteps the issue in another way)

[reply]

In Section Seekers of Perl Wisdom