On Sun, 21 Apr 2002, Steve Fink wrote:
> On Sun, Apr 21, 2002 at 02:15:42AM -0700, Brent Dax wrote:
> > Chip Salzenberg:
> > # While editing *.pmc, I'm inclined to make various style
> > # details consistent. But I don't know whose style rules rule
> > # in *.pmc. If necessary, I'll be glad to create a pmc style guide.
> >
> > I'm not sure what the correct style is, but the coding style PDD should
> > be a good starting point. ( know that the indents are wrong, for
> > example.)
>
> The PMCs were all written at different times, and advances have passed
> them by at different points in their history (eg, inheritance). They
> could probably use a brutal rewrite by a consistent hand. Certainly
> nobody's going to complain.
s/could probably use/need/; as they stand, the PMCs fiddle about with
each others internals in ways that are simply wrong. For instance,
consider this code from perlint.pmc:
void concatenate (PMC * value, PMC* dest) {
STRING* s;
s = string_concat(INTERP,
SELF->vtable->get_string(INTERP, SELF),
value->vtable->get_string(INTERP, value),
0
);
dest->vtable = &Parrot_base_vtables[enum_class_PerlString];
dest->vtable->set_string_native(INTERP,dest,s);
}
By stomping on the destination PMC's vtable before assigning the string,
we're throwing away all knowledge of its contents, and thus won't be
able to do the right thing in cases when that PMC represents a tied
variable, for instance.
I've made a start on fixing this, and other breaches of encapsulation,
with my recent patch to perlstring.pmc, but I've been loathe to go
any further until I get some feedback from Dan and/or Jeff about
whether I'm fixing it right. If somebody else wants to take over this
I'd only be too happy -- I can go back to beefing up the test suite
(which is pretty sparse at the moment as far as the PMCs are concerned).
Simon
