On Wed, Jul 06, 2005 at 11:28:47AM -0400, Stevan Little wrote:
: 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.

Most of these submethods will have a generic ordinary method backing
them up in Object.  But Object::new isn't where that magical call to
BUILDALL happens.  It's the SomeClass.bless that does it magically,
and the default Object::new just happens to call .bless.

: 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.

But we want people to be able to add BUILD methods easily.

: 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.

Well, bear in mind that declarators like "submethod" are just disguised
calls on some metaobject already.

: 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 ...

Well, sure, except you might want the methods in Object to be
inherited, and use submethods only for specific overrides of the
default.  But the syntax seems a bit klunky.  I suspect it's just
something more like "Object does FreezeThawDefault".

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

I don't think that's terribly far away from what we've got already.


Reply via email to