"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.
We have e.g. this PIR snippets:
.sub main :main
cl = newclass 'Foo' # a class isa/hasa namespace ?!
That's an interesting question. It seems we've gone down the Perl5-esque
line of thought to some degree (e.g. we do objects by associating some
"thing" with a particular namespace). At the moment it feels to me like a
class is associated with some namespace N that contains the methods and
globals (static attributes) associated with that class, but the class is
conceptually "in" the parent namespace of N. Whether that's the Right
Thing, I'm not sure. If it's not, then we're going to need some seperate
way of associating methods with a particular class. I think that's an
argument for maintaining the status quo...
...
.end
.namespace ['Foo'] # namespace 'Foo'
.sub __init :method # a method &Foo::__init
...
.end
Currently '__init' is stored with:
store_global "Foo', '__init', $PSub
(Actually, if the class already exists, the C<add_method> vtable is
used, but that just does C<store_global> too) But usually, this happens at
compile-time,
or PBC-load-time, when the class 'Foo' doesn't yet exist.
Therefore C<Foo> can't be stored into the proposed
class->vtable->namespace,
as there is no such class (yet).
To actually implement this (and assuming that my thoughts so far are
correct)
I was thinking about this strategy:
The usage of the C<.namespace> directive causes the creation of a new
namespace PMC with that name. Additionally the namespace PMC is registered
as a type. This needs a bit of additional code that prevents instantiation
of namespaces.
How would this intereact with, say, getclass? Would getclass only actually
find real classes, not just anything registred as a type?
When now at runtime C<newclass 'Foo'> is executed, we find the existing
namespace PMC (with all the statically visible methods inside) and just
promote the namespace PMC into a class PMC.
Is this sane?
I'd really like a way of just saying I want the methods in a class PMC
statically too - I guess if we had that this problem goes away? But it's
also helpful for other reasons. If you're loading a huge class library,
having to have a :load sub that does many hundreds of newclass calls really
slows down startup. (I've been there and done it. A PBC that contains just
empty method bodies for .NET's System.dll took several seconds to do that.
Admittedly, one :load sub per class, which sucks. But not having to do
newclass at all by having all the ParrotClass PMCs created and frozen at
compile time for the statically known classes would be better.)
Hope this helps,
Jonathan
