Objects, init, and vtable limits

[Dan Sugalski]

We've gone back and forth on this before, and it's time to go for yet
another round.

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

I'm up for discussion on this, as well as other options, so... have at it.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Leopold Toetsch]

Dan Sugalski <d...@sidhe.org> wrote:

> 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
...
.pcc_sub _init:
print "init\n"
print P5
...

$ parrot o.pasm
init
hello

leo