Tom Christiansen wrote:
>
> 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.
Sort of. Actually, I want to not care. Adding a :method constraint
doesn't help (actually hurts) because then the two styles - object and
function oriented - aren't freely interchangeable.
> 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.
That's what I like about this. self() can be used anywhere, in any
context, and it Does The Right Thing (assuming you're not a bozo).
> 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.
It's probably not that common. But it is very useful. CGI.pm uses it
with great benefits, and File::Remote lets you use an object-oriented
style or lets you override the builtin open() et al operators. In these
cases and others, being able to choose either interface is very
powerful. And self() eliminates the needless leaps and bounds you have
to go through for this to work.
Plus, don't overlook that self() is not just a replacement for shift in
the first line of a sub. :-) It is a full context function, just like
want(), ref(), and caller() (thanks Bart).
-Nate
