Dan Sugalski wrote:
DS> TheObj *foo;
DS> SV *new_sv;
DS> foo = new TheObj("A parameter");
DS> sv = perl_new_sv();
DS> perl_make_sv_object(sv, "Some::Package", foo, &dispatch_routine,
DS> &destroy_routine);
DS>
DS> perl_return(perl_make_ref(sv));
Ken Fox wrote:
KF> Are you really thinking about keeping "SV *" and two-level refs
KF> and all that? That sounds an awful lot like the current internals.
DS> SV * as it exists in perl 5? No. Some magic cookie that perl's internals
DS> passes to extension code? Yep, you bet. Probably should've used PMC instead
DS> of SV * to distinguish them.
Ok. I just want to make sure you realize that by not returning the (SV *)
on *every* mutating operation that you've eliminated the possibility of
storing values in the (SV *) itself.
Here's an example of something that might be nice.
There are 3 immediate types and 1 extended type -- the bottom 2 bits
of the (SV *) are used to identify them:
SV *x
if (x & 3 == 0) x is an extended type -- a pointer to an "object"
if (x & 3 == 1) x is an integer -- value = x >> 2
if (x & 3 == 2) x is a string constant -- value = constant[x >> 2]
if (x & 3 == 3) x is [something else that can fit in 30 bits]
This is fairly traditional value boxing that is used in many lisp
implementations. Yeah, I know bit ops suck and lots of values will
end up being pointer derefs anyways. It seems like something we
should investigate -- the impact on the perl API shouldn't be too
big.
> Your extended way's cool too--RFC it and we can do that as well.
I've been wanting to. It would be nice (at least for me) for you to
start suggesting more RFC "assignments" like this. Community is not
the same as "no ownership" and there are a lot of people that have
a lot more ownership of internals than me.
- Ken
