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 ))


Reply via email to