On Feb 12, 2006, at 3:07, Jonathan Worthington wrote:
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?
I presume that 'getclass' would say "Class '%s' doesn't exist", if the
thing is just a namespace.
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.)
Yeah. ParrotClass (and Object) already have freeze/thaw implemented and
there is one test that freezes an object with an attribute and with
it's class. By having all class-related items inside the class PMC,
thawing a full class hierarchy should work as well.
(t/pmc/freeze.t:476)
Hope this helps,
Jonathan
leo
