Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: Re: Why breaking can() is acceptable

by runrig (Abbot)
on Apr 07, 2004 at 00:44 UTC ( #343167=note: print w/replies, xml ) Need Help??

in reply to Re: Why breaking can() is acceptable
in thread Why breaking can() is acceptable

If a package/class has an AUTOLOAD sub, will you be able to decline to handle a method, but say "I don't want to handle this, but keep looking in the inheritance tree"? Say for some reason, you want your class to handle get_* methods, and the next class in ISA (or whatever the Perl 6 equivalent is), to handle set_* methods; nevermind how good/bad of a design this is :)
  • Comment on Re: Re: Why breaking can() is acceptable

Replies are listed 'Best First'.
Re: Re: Re: Why breaking can() is acceptable
by TimToady (Parson) on Apr 07, 2004 at 02:12 UTC
    Yes, you can always call "next METHOD" to pass the buck to the next method in the list of candidates. Though an AUTOLOAD is going to be pretty far down the pecking order, because Perl will prefer all declared methods over all wildcard methods, and autoloading is one form of wildcarding. So only an AUTOLOAD in a parent class (or a sibling class, since these are "next" semantics) is possible in the remaining list of candidates.

    Though as for get_* and set_* methods, those would be non-standard in Perl 6. Perl's accessor methods will not be split into get and set methods. Rather, they'll be single methods that are lvaluable if you want to allow setting.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://343167]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2023-03-24 03:19 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (60 votes). Check out past polls.