>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
