PMC implementations are hard to read

chip on 2005-03-29T17:31:31

I think PMC method implementations should be easier to read (and write) than they currently are. PMC methods as they are currently written are almost compilable with a C compiler, modulo some magic words like "SELF", and that makes them highly redundant. Even a little simple filtering should let us kill all those blank lines and pod text up against the left margin. And there's a lot of cross-file redundancy we can kill with some vtable knowledge. Where now we have:

/*

=item C

Returns a C PMC.

=cut

*/

static PMC* undef(Interp* interpreter)
{
    return pmc_new(interpreter, enum_class_PerlUndef);
}

Look at all the redundancy there. And consider all the vtable methods that have multiple implementations across many PMCs. Making programmers type the same thing over and over is just mean; it all the fun out of the coding. Something like this would be a lot better:

=method undef
=returns a C PMC.
{
    return pmc_new(interpreter, enum_class_PerlUndef);
}

Everything else that's omitted here is, or should be, available elsewhere ... every implementation of the given vtable method must have the same signature, so why make every implementor spell it out?

If we want people to help us finish the PMCs, why not make their job a little more pleasant?


No reason at all

Elian on 2005-03-29T23:00:19

Other than time, of course. :)

Like the opcode files, PMC source is lightly processed C code, with just enough filtering to make things work out OK. Then it was on to the next thing needing thumping...

Formatting is b0rken

chip on 2005-03-30T02:35:59

I don't know why, but there's text missing after the code snippets. I've asked pudge about it and I'll fix it as soon as I know how.