Okay, here's a thought. We might as well just do this once, and do it
right. So I'm thinking we:
Add a vtable slot to the PMC vtable inv_init (or something like that,
the name's not that big a deal), define it as an invokable method
taking parameters as the current calling conventions, and be done
with it. Basically we special-case this one method and hoist it up
into a vtable slot. IMCC for it'd look something like:
(result1, result2) = $Pxxx.inv_init(1, 2, "foo", "bar", $Pbaz)
If the class wants its heavyweight constructor multi-dispatched, then
it can go do that.
If this seems not too insane to implement (or, alternately, so insane
it's obviously the correct thing to do) then we can hash out the
details and get it done.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> Add a vtable slot to the PMC vtable inv_init (or something like that,
> the name's not that big a deal),
vtable->new and "__new"?
> ... define it as an invokable method
> taking parameters as the current calling conventions, and be done
> with it. Basically we special-case this one method and hoist it up
> into a vtable slot. IMCC for it'd look something like:
> (result1, result2) = $Pxxx.inv_init(1, 2, "foo", "bar", $Pbaz)
Two return values? What is $Pxxx: a class PMC or an empty Undef object
of some kind?
I think we should have:
Pclass = getclass, "Foo"
Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument
and that be special-cased to call VTABLE_new according to calling
conventions.
How does that correspond to the proposed CONSTRUCT property? Is that
still needed?
leo
Those are a little too similarly named. We should have something more
distinct, I think.
> > ... define it as an invokable method
>> taking parameters as the current calling conventions, and be done
>> with it. Basically we special-case this one method and hoist it up
>> into a vtable slot. IMCC for it'd look something like:
>
>> (result1, result2) = $Pxxx.inv_init(1, 2, "foo", "bar", $Pbaz)
>
>Two return values? What is $Pxxx: a class PMC or an empty Undef object
>of some kind?
$Pxxx is an uninitialized object of the class you're creating, but
that won't work at the PIR level. PIR combines the new and init
functions together, which I always forget.
>I think we should have:
>
> Pclass = getclass, "Foo"
> Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument
>
>and that be special-cased to call VTABLE_new according to calling
>conventions.
Still don't like __new, but otherwise that works out OK. It'd call
VTABLE_init_extended or whatever we'd name the entry.
>How does that correspond to the proposed CONSTRUCT property? Is that
>still needed?
I don't think CONSTRUCT would be needed with this.
> Still don't like __new, but otherwise that works out OK. It'd call
> VTABLE_init_extended or whatever we'd name the entry.
Ok. It is actually "new_extended" now. It's creating new objects, so
"init_extended" didn't totally match the behaviou?r.
Initial tests are in as well as a fallback in default.pmc that
constructs a new PMC without initializers.
leo
Oh. This isn't right. The extended stuff's extended initialization,
just like init is now. It works on the PMC it's attached to, rather
than allocating a new PMC from the pool.
> Oh. This isn't right. The extended stuff's extended initialization,
> just like init is now. It works on the PMC it's attached to, rather
> than allocating a new PMC from the pool.
I was always talking about a class method that returns new objects like
in the example above.
If we need extended initialization too, then that's a different set of
opcode/vtable.
The C<new_extended> matches nicely Python's object construction, like:
c = complex(1,2)
where "complex" actually is a class.
leo