Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Why breaking can() is acceptable

by stvn (Monsignor)
on Apr 06, 2004 at 04:47 UTC ( #342834=note: print w/replies, xml ) Need Help??

in reply to Why breaking can() is acceptable

I'm going to agree with dragonchild, if you are going to do AUTOLOAD stuff then you should implement a version of can for your class. This is basic interface polymorphism (another of chromatic's pet peeves), you should be able to expect that inherited methods called on your object behave in a resonably obvious/intuative way or have a very good reason not too. Sometimes, this means not relying on the default implementation (UNIVERSAL::can) and instead write a custom implementation.

Part of the idea of using AUTOLOAD is to hide the implemenation (methods not being implemented) from the user of your class. If in doing so you break can (an expected inherited method of the UNIVERSAL base class) then you are breaking the object, and your code is incomplete.

I would even go so far to argue that if you cannot write a version of can that functions as a transparent replacement, you should re-think your use of AUTOLOAD in the first place.

I see no reason why it should be left broken or that you would need to make method stubs. It should work as expected, nothing more, nothing less.


Replies are listed 'Best First'.
Re: Re: Why breaking can() is acceptable
by tilly (Archbishop) on Apr 06, 2004 at 05:10 UTC
    I believe that getting a replacement can method to work absolutely correctly in all situations is far harder than it looks. I tried to explain some (not all!) of the issues in my root node. If you think that it is easier than I do, then post an interesting example of an AUTOLOAD and how you'd override can, and I'll try to demonstrate how - by your standards - your code is incomplete.

    If the task proves difficult for you, right after you just read a description of some of the things that can go wrong, can we both agree that expecting people to consistently get it right is unrealistic?

      I never said it would be easy, I just said that you shouldn't break can for the sake of AUTOLOAD. But I am not a big fan of AUTOLOAD, while I do make (occasional) use of can so I would sooner throw away AUTOLOAD before I gave up can.

      I will take you up on your challange, but with one change. I ask that you post and interesting example of AUTOLOAD, for which I will write a version of can. Partially because I don't like or use AUTOLOAD very much and to be honest would have a hard time coming up with an interesting example, and partially because I am not a fan of writing vaguely specified code for others to shoot holes into. Something like this is clearly complex, I do not deny that, but if you have a solid and well thought out implementation of AUTOLOAD I expect it would be possible to write a version of can to go with it.

        Larry Wall's original intention is shown pretty well by Shell. You could choose to pick on various other core modules that use AUTOLOAD.

        Some nodes where I have used AUTOLOAD include Class::FlyweightWrapper, Re (tilly) 1: Nested Classes and the poorly implemented Re (tilly) 1: Reverse Inheritance Irritance.

        Note that when I've chosen to use AUTOLOAD in the past, it tends to be short. A doable solution which takes considerable overhead to implement is going to underscore my point that, as Perl is currently structured, using AUTOLOAD and can together runs into trouble.

      The following snippet is taken from that example I alluded to above.
      # This exists to provide object-specific can() functionality. # 1) If this is an object, check to see if the method is an element na +me. # 2) If either is not true, redispatch to the parent's can() method. + sub can { ( ref($_[0]) && UNIVERSAL::isa( $_[0]->elements, 'HASH' ) && exists $_[0]->elements->{$_[1]} ) || ( $_[0]->SUPER::can($_[1]) ); } sub AUTOLOAD { (my $name = our $AUTOLOAD) =~ s/.*::([^:]+)$/$1/; my $self = shift; unless ($name eq lc $name || exists $self->element_classes->{lc $n +ame}) { return eval "$self->SUPER::$meth(@_);"; } $self->elements->{$name} = shift if @_; $self->elements->{$name}; }

      A few notes:

      1. This is a container object, providing a unified interface to parsing stuff. It acts as a record and the elements are the various columns. Each record may have different columns and the goal was to provide a way of allowing the user to call the column name as a method and get the column object.
      2. element_classes is a method which returns a hashref of name-class pairs. The name is the name of the column as provided to this object in the constructor. The class is the class of the column.
      3. elements is a hashref which actually contains the column objects in name-object pairs. It is guaranteed that the names from element_classes() will be identical to the names from elements().

      This implementation has the added benefit of the fact that it's currently working in production. Now, nothing inherits from it (yet) and I do not use MI in production code, for the reasons well-cited elsewhere.

      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://342834]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (4)
As of 2017-02-21 01:48 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (305 votes). Check out past polls.