>The current scheme of PMC instantiation works mostly fine for >scalars and other simple types, but it's a bit limited. It allows >only one initializer (see init_pmc in docs/pdds/pdd02_vtables.pod).
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:
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
Dan Sugalski <d...@sidhe.org> wrote: > 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?
>> 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"?
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:
>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. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski <d...@sidhe.org> wrote: > At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote:
>> 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.
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.
>Dan Sugalski <d...@sidhe.org> wrote: >> At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote:
>>> 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.
>Ok. It is actually "new_extended" now. It's creating new objects, so >"init_extended" didn't totally match the behaviou?r.
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. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski <d...@sidhe.org> wrote: > At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote: >>Dan Sugalski <d...@sidhe.org> wrote: >>> At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote:
>>>> 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.
>>Ok. It is actually "new_extended" now. It's creating new objects, so >>"init_extended" didn't totally match the behaviou?r. > 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:
