Thomas,
On Jul 6, 2005, at 10:19 AM, TSa (Thomas Sandlaß) wrote:
S12 says in the section Submethods: "A submethod is called only when a
method call is dispatched directly to the current class."
And without finding a reference I think it was said that "the invocant
of a submethod is a class object".
I took that statement to mean that methods were not inherited, and that
they can only be called from methods within the class they were
defined.
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.
This is a possibility, however, i think that submethods are more
valuable if they dealt with invocants rather than just with classes
(metaclasses).
It seemed to me from A12 that submethods are meant to define an
interface of some kind, the BUILD/DESTROY submethods being the perfect
example. However this means that BUILDALL and DESTROYALL need to be
fairly magical. I say this because BUILDALL would have to extract some
kind of class list from it's invocant, and call
$self.SomeClass::BUILD() on each class. And since BUILDALL is
(supposedly) defined in Object, (and I assume it too is a submethod),
it becomes critical (in some cases) for Object::new to be called.
=begin RANT/SUGGESTION
While I like the idea of infastructural methods, I think maybe we
should place more restrictions on them. Ideally the object model itself
would create a set of these "interfaces". One for creation
(BUILD/BUILDALL) and for destruction (DESTROY/DESTROYALL), and maybe a
few others. And then the model itself would utilize them, but the user
would not (easily) be able to add to these submethods.
I think this would greatly simplify the concept of submethods, and also
allow for more advanced users to add new "interfaces" to the object
model. This could (theoretically) allow for low-level manipulation of
the object model while still making it simple for not-as-advanced users
to use it easily by just following the interface.
For instance, here is a very simply and naive example of a persistant
interface of sorts:
Object.meta.add_submethod('FREEZE' => sub { ... });
Object.meta.add_submethod('THAW' => sub { ... });
Object.meta.add_submethod('FREEZEALL' => sub ($self:) {
for $class -> $self.meta.get_class_list() {
$self.($class)::FREEZE();
}
});
etc etc etc ...
Then a user could simply define a FREEZE and THAW submethod in each of
their classes they want to be persistent.
Or something like that :)
=end RANT/SUGGESTION
Anyway, just a thought.
Stevan
But mind the sig!
--
$TSa =:= all( none( @Larry ), one( @p6l ))
