Returning new PMCs (again)
David Robins
to create and return a new PMC in PMC ops that take a "PMC* dest" param?
Should I submit my pmc_placement_new() (also in that thread) as a patch?
(morph isn't sufficient because I don't want to coerce the destination into
anything, I want to clobber it, so cycles are wasted if e.g. dest is
presently (say) a number, and I morph it into a string, which does some sort
of sprintf call, and then I set the string to an arbitrary new value).
Thanks,
Dave
Isa. 40:31
Dan Sugalski
If the op defines the destination as getting a brand-new PMC, then
just stuff the pointer to it in the destination and let the GC pick
up the original if necessary.
If the op defines that it will assign a value in the destination,
then call the set_value vtable method and let the destination PMC
deal with the incoming value as it needs to.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
David Robins
> At 1:29 PM -0500 12/31/02, David Robins wrote:
> >Maybe I missed it in the original thread, but what was the resolution on how
> >to create and return a new PMC in PMC ops that take a "PMC* dest" param?
>
> If the op defines the destination as getting a brand-new PMC, then
> just stuff the pointer to it in the destination and let the GC pick
> up the original if necessary.
I don't think any ops do that presently (that would take a PMC** param).
> If the op defines that it will assign a value in the destination,
> then call the set_value vtable method and let the destination PMC
> deal with the incoming value as it needs to.
How do I set the dest to false (remembering that in Ruby, 0 is not false)?
Dave
Isa. 40:31
Dan Sugalski
>On Tue, 31 Dec 2002, Dan Sugalski wrote:
>
>> At 1:29 PM -0500 12/31/02, David Robins wrote:
>> >Maybe I missed it in the original thread, but what was the
>>resolution on how
>> >to create and return a new PMC in PMC ops that take a "PMC* dest" param?
>>
>> If the op defines the destination as getting a brand-new PMC, then
>> just stuff the pointer to it in the destination and let the GC pick
>> up the original if necessary.
>
>I don't think any ops do that presently (that would take a PMC** param).
Oh, sure, lots do. Remember the ops get a pointer to the PMC
register, which is itself a pointer. Whatever you stuff in there is
what the register is set to.
PMC vtable functions, on the other hand, are given a destination to
assign into,and they have to respect the assignment function of the
destination. There's no real choice there, by design. (Still open for
debate)
> > If the op defines that it will assign a value in the destination,
>> then call the set_value vtable method and let the destination PMC
>> deal with the incoming value as it needs to.
>
>How do I set the dest to false (remembering that in Ruby, 0 is not false)?
Get a new RubyFalse PMC and stuff it in. If we don't have any good
utility functions to get new PMCs by class name or class number then
we need to fix that.
David Robins
> >I don't think any ops do that presently (that would take a PMC** param).
> Oh, sure, lots do. Remember the ops get a pointer to the PMC
> register, which is itself a pointer. Whatever you stuff in there is
> what the register is set to.
Right, I meant PMC vtable, not ops.
> PMC vtable functions, on the other hand, are given a destination to
> assign into,and they have to respect the assignment function of the
> destination. There's no real choice there, by design. (Still open for
> debate)
Well, I've given my reasons why I think they should return PMC*s (or take a
PMC** as output) in the other thread, mainly
(a) it's more natural for an op to return a 'new' value (as e.g. C++ does,
or perl's own "use overload;")
(b) it's hard to deal with having to accept and handle a destination PMC
of unknown type
the only reason against returning new PMCs is a possibly loss of efficiency
but with fixed-size header allocation and GC that shouldn't be too bad, but
OTOH when you do something a million times anything begins to add up.
If you think the "placement pmc_new" idea/code was good I can submit it as a
patch.
> > > If the op defines that it will assign a value in the destination,
> >> then call the set_value vtable method and let the destination PMC
> >> deal with the incoming value as it needs to.
> >How do I set the dest to false (remembering that in Ruby, 0 is not false)?
> Get a new RubyFalse PMC and stuff it in. If we don't have any good
> utility functions to get new PMCs by class name or class number then
> we need to fix that.
How exactly would I do this then? What's the accepted way to "get a new
RubyFalse (or RubyBoolean) and stuff it in"?
Dave
Isa. 40:31
Dan Sugalski
>On Tue, 31 Dec 2002, Dan Sugalski wrote:
>
>> >I don't think any ops do that presently (that would take a PMC** param).
>> Oh, sure, lots do. Remember the ops get a pointer to the PMC
>> register, which is itself a pointer. Whatever you stuff in there is
>> what the register is set to.
>
>Right, I meant PMC vtable, not ops.
Ah, OK, that's different. :)
Ripping out the rest of the stuff, this boils down to a matter of
behaviour. What you're looking for is "perform operation and return
value" semantics, while the vtables specify "perform operation and
assign value" semantics. This is generally the more-likely to be used
way, and we've gone with it for performance reasons.
In those cases where there is no destination of the assignment, you
need to create an empty PMC of the appropriate type, or something
that can become the appropriate type, and pass it into the vtable
method.
This also brings up some issues of object behaviour, which I think I
need to specify better, so I will in a more appropriately titled mail
message. :)