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.
> 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
