On Thu, 15 Nov 2001, Simon Cozens wrote:
> Remember that PMCs have a data area which is a void
> pointer; I'm connecting that to a structure which has
> integer, number and string slots. Those of you familiar
> with Perl SVs will know exactly where I'm coming from.
Umm, I'm not sure /how much/ better this is, from a maintainablity point
of view, but you could declare your own struct PMC_scalar, which is the
same as struct PMC, but with the data being a struct PerlScalarData*
instead of a void*.
You could also make a function (or, yes, a macro), private to
perl_scalar.c (or whatever it's called; I'm on the windows side of my box
right now).
struct PerlScalarData* data(struct PMC* pmc) {
return (struct PerlScalarData *)(pmc->data);
}
That'll help a little:
> static INTVAL Parrot_scalar_get_integer (struct Parrot_Interp *interpreter, PMC*
>pmc) {
> if (pmc->flags & PS_INTEGER_OK) {
> return ((struct PerlScalarData *)(pmc->data))->intdata;
return data(pmc)->intdata;
> } else if (pmc->flags & PS_NUMBER_OK) {
> pmc->flags |= PS_INTEGER_OK;
> return ((struct PerlScalarData*)(pmc->data))->intdata
> = (INTVAL)(((struct PerlScalarData*)(pmc->data))->numdata);
return data(pmc)->intdata = (INTVAL)(data(pmc)->numdata);
> ...
> }
>
> And that's mild. I could typedef "struct PerlScalarData" to "PSD",
> but that wouldn't really help that much. And I could fudge it all
> with macros, but that's a Perl 5 thing to do.
I don't see doing it with a macro as too bad, so long as the macro is
decently localized. (If you don't like macros because of their
preprocessor nature, use a function; it should inline just fine.) And it
seems like it would be, given that a scalar is Just Another PMC.
-=- James Mastros
--
Put bin Laden out like a bad cigar: http://www.fieler.com/terror
"You know what happens when you bomb Afghanastan? Thats right, you knock
over the rubble." -=- SLM
