Right now, we can create new PMCs by calling the class init method.
It takes no parameters which somewhat limits the utility of the thing
as a true initializer. There's an init vtable method that takes a
property PMC, but that's kind of awkward.
Now, we've three real options here. We can:
1) Treat the init method as an allocator, and leave initialization to
an explicit sub/method call
2) Have one single vtable method that has a different set of calling
conventions from every other method and sub available from bytecode
3) Make new use the registers and obey the calling conventions
Now, I don't really like #3, as it's damned inconvenient. #2 has this
nasty inconsistency to it that I'm not thrilled with either, though I
can definitely live with it. #1 leaves us with the possibility of
split allocation and initialization and I've been warned about that
as a Bad Idea. (OTOH we're at a low-enough level that it's arguably
I'm up for discussion on this, as well as other options, so... have at it.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> Right now, we can create new PMCs by calling the class init method.
> It takes no parameters which somewhat limits the utility of the thing
> as a true initializer.
Does it or not?
newclass P1, "Foo"
find_global P2, "_init"
store_global "Foo", "__init", P2
find_type I1, "Foo"
new P5, .PerlString
set P5, "hello\n"
new P3, I1
$ parrot o.pasm