Larry,
Okay, I reviewed A12, and I think I have now managed to implement the
proper object creation behavior in the meta model.
Currently it is somewhat limited, but this is the order of events (as I
understand it from A12).
- First Object.new calls Object.bless passing all named arguments.
- Object.bless then calls Object.CREATE which then returns a data
structure for the instance (P6opaque only right now).
- Object.bless then "blesses" this structure (since the prototype is in
Perl5 it just passes the structure returned by CREATE into
CORE::bless(), I am sure it will be different in the proper Perl6).
- Object.bless then calls $instance.BUILDALL (again passing all the
named params).
- $instance.BUILDALL then does a post-order traversal of the class
hierarchy calling BUILD on all classes (again passing in the named
parameters).
Of course CREATE, BUILDALL and BUILD are not proper submethods yet
because Perl6::Object is not self defining yet. And it only supports
'P6opaque' right now, but I think I have the ordering of events
correct, however, please correct me if I am wrong.
Oh yeah, and all that silliness I wrote below,.. ignore it :)
Thanks,
Stevan
On Jul 6, 2005, at 1:45 PM, Larry Wall wrote:
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.
: =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.
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.
Larry
