Larry,
On Jul 13, 2005, at 2:30 PM, Larry Wall wrote:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However,
it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that impression, it's giving the wrong
impression.
Subs, methods, and anything in between all live in the same namespace.
The class above is illegal because you're trying to give two things
the name &bar in the absence of a "multi".
Horray!!!!
: Can submethods only be called from within the class (like private
: methods)?
No, they can be called from anywhere. They're just constrained to
work only when a dispatcher's idea of "current class" matches the
actual class, where "current class" usually means the actual class
of the object in question, but can also mean an ancestral class when
we're doing BUILDALL, for instance.
The way I am viewing the notion of "current class" for submethods
currently is:
From inside another method or submethod:
- a submethod should only be called from the class which defines it.
This means that since Object::bless() calls Object::BUILDALL() it is
all well and good, assuming you have not overridden bless() in your
class, and are calling it $class.bless().
(Object::BUILDALL of course then digs into the metaclass to call
BUILD() for all the superclasses in post-order. I am not sure how to do
that otherwise, submethod or not.)
However, if you define MyClass::bless, then you will need to define
MyClass::BUILDALL as well.
Or is it possible just do $self.Object::BUILDALL()? So can I call a
submethod from a different class if I fully qualify it?
From outside a method (in "user" space):
- the invocant of the submethod must be a direct instance of the class
in which the submethod is defined. No inheritance involved.
Maybe this is too strict, though? What do you think?
There's some kind of "yes I mean
you" notion in the dispatcher. It comes out in user-visible terms
in .*foo calls but not ordinary .foo calls,
I am not familiar with .*foo calls? Can you elaborate?
which call a submethod
only when the object is actually that type, and otherwise look for an
ancestral method of that name.
Yes, to expand upon my above statements. The method resolution would
begin looking in the local submethod table, then move onto the local
method table, and then on up the superclass hierarchy. Is that correct?
Thanks,
Stevan
