On Wed, Jan 02, 2002 at 11:49:40PM +0000, Alex Gough wrote:
> On Wed, 2 Jan 2002, Steve Fink wrote:
>
> > This patch makes pmc2c.pl emit #line directives to .c files so the
>
> Good plan, saves me hitting M-x revert-buffer every time I try to
> change something when hunting. Is this likely to make it harder to
> charge through the actual C with a debugger, if so, can an option to
> disable the numbering be added?
Sure, I'll throw it in. But it's probably not really needed, at least
not yet -- right now, the only relevant things in either the .pmc or
..c files are the method bodies, and those are pretty much identical
between the two. But you're right, somebody'll want to know exactly
what INTERP expands to.
> > The later patch implements "PMC inheritance": any unimplemented vtable
> >
> > I really just implemented this so that I could muck with the vtable
> > without modifying perlint.pmc, perlnum.pmc, etc. every time I made a
> > change, and the existing '= default' is insufficient for that. I also
> > think that default.pmc probably ought to have an implementation like
> >
> > die("Unimplemented vtable method called.");
>
> I think default.pmc is for those people too lazy to write the methods
> themselves, exploding is probably bad (exploding because someone tried
> to access an array element of a non array isn't though, so sometimes
> this *ought* to be the default, but not always).
I couldn't tell what the intention was. I'd guess one of:
1. an abstract base class (so calling things here should fall down go boom)
2. a default implementation (x++ -> x=x+1 sort of thing)
3. a stub to have something to put into the vtable slots (but then why not NULL?)
4. a combination of the above, depending on the method.
> Apart from that, inheritance good, but we need to be careful to
> avoid making our classes into a C++-like baroque monstrosity of
> twisty little inter-relations and weird syntax.
I guess I'll have to back out the multiple inheritance bit, then...
(just kidding)
> Remember also that one day (my son...) we'll need to parse and
> generate the .c code without the helping hand of perl, so don't get
> carried away with making a little language we don't really need.
Hrm? Why? What would eliminating the dependency on perl help? We can
always ship the generated .c files. Or am I missing the point?
