Front page | perl.perl6.language.objects |
Postings from August 2000
>It's a pain if you want to support both function-oriented and >object-oriented calling forms, as CGI.pm does. For example, you can use >both of these: > print header; > print $r->header; >with CGI.pm. Now you need a self_of_default special method, since >sometimes $_[0] has a class ref and sometimes it has the first method >argument. So it seems that what you're saying is that you'd like a way to *know* for certain whether you were invoked as a method -- or not, as the case might be. I've not looked at the relevant RFCs should such exist (I was out hiking in the desert for two and half weeks), but there's long been musing about using :method as an optional or mandatory hint to break the "a method is just a subroutine" mumblage. This is appealing because you would no longer "accidentally" inherit a package's subroutines as methods just because you inherited from them. There may be some connection between this notion and what you would do. Then again, in days of old when porters were bold and objects were just invented, Dean used to preach to us not to be overly concerned about whether the object invocation syntax had been subverted via direct calling of the subroutine. Finally, while I may be wrong, I don't really get the idea that this situation seen in CGI.pm in which a sub is sometimes a function called with N arguments and sometimes a method called with N+1 arguments is one which is in the least bit common. In fact, I've even heard argued its (un)desirability in the first place. --tom