On Wed, Jul 06, 2005 at 04:19:40PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Stevan Little wrote:
: >You seem to indicate that submethods are not to be used on instances,
: >and instead to be used on the underlying metaclass. I did not see
: >anything of the sort in (Syn|Apoc)12 or in my (limited) search of the
: >mailing list. Can you point me to that information?
:
: S12 says in the section Submethods: "A submethod is called only when a
: method call is dispatched directly to the current class."
Ah, you're reading a little too much into an imprecise statement.
The intent is not to limit it to class methods--it's using "current
class" to be inclusive of its members. It should say something more
like
A submethod is called only when a dispatcher decides to call
a method via this exact class. This can be because
a) this class, out of all the candidates, happens to be the
class the dispatcher is currently thinking about, or
b) the method call itself is qualified to specify which class
to call explicitly (and for that particular class only, the
constraint on exact class matching is relaxed as if it were
an ordinary subroutine call). Or
c) you call a submethod as an MMD function, in which case the
first invocant of a submethod is constrained to be an exact
class match, or resolve to an ordinary method. Or
d) you call it as a qualified function name, in which case it's
a simple function call.
: And without finding a reference I think it was said that "the invocant
: of a submethod is a class object".
You won't find that one because I don't think anyone ever said it.
: From this I have derived what I said. Nonetheless there seems to be
: some overlap in particular in the construction process which is
: characterized as involving an unitialized object. So in that case
: some macro magic might make the instance available to the submethod.
: But this will be a non-invocant parameter.
Nope, it's just the normal invocant. Submethods differ from ordinary
methods only in not being derivable. (Well, and the fact that they
often operate on partially instantiated objects, as you point out.)
Now in the particular case of a CREATE submethod, you have to get the
class because object isn't created yet. But generally you don't
need to define one of those unless you don't want to use the built-in
opaque type. So the usual course of events is that some constructor
(probably called "new") calls MyClass.bless(%args) and that in turn
calls
my $newobj = MyClass.CREATE(%args);
$newobj.BUILDALL(%args)
which, after calling all the ancestral BUILDs, calls
$newobj.MyClass::BUILD(%args)
or maybe
$newobj.=MyClass::BUILD(%args)
or possibly even
MyClass::BUILD($newobj, %args)
if it doesn't want to fail over to Object::BUILD in the absence of
MyClass::BUILD.
But all that's behind the scenes. The basic cargo cult version
for naive users is, "Write a 'BUILD' submethod if you want to
initialize the attributes with dynamic data that can't be expressed
with default values. And write your own constructor if you don't like
the built-in default constructor. Just make sure your own constructor
calls $class.bless(%args)."
Larry
