On Wed, Jan 16, 2002 at 11:11:10AM -0500, Andy Dougherty wrote:
> diff -r -u parrot/classes/pmc2c.pl parrot-andy/classes/pmc2c.pl
> --- parrot/classes/pmc2c.pl   Thu Jan  3 21:29:18 2002
> +++ parrot-andy/classes/pmc2c.pl      Wed Jan 16 10:57:04 2002
> @@ -228,7 +228,12 @@
>  
>    my $includes = '';
>    foreach my $class (keys %visible_supers) {
> -      next if $class eq $classname;
> +      # This used to be 
> +      #      next if $class eq $classname;
> +      # But most files (e.g. default.c) should include their own headers
> +      # (e.g. default.h).  I'm not sure what this was attempting to
> +      # guard against, so I've left this comment in as a reminder.
> +      # -- A.D.  1/2002.
>        $includes .= qq(#include "\L$class.h"\n);
>    }

That was me. I'm still unsure of the best way to do this. Before I
added inheritance, there were no .h files (except for default.h, which
was hand-generated), and more importantly, all of the PMC methods were
static. I was trying to make as little a change as possible, so first
I just spewed out prototypes for everything a particular .c needed,
then later decided that was silly and went the .h route. The line you
commented out was purely a thinko resulting from that process.

However, I'm still not sure if we want to pollute the global namespace
with all of the method names for all PMC classes. I wonder if it would
be better to export a single Parrot_<class>_fillin_vtable function
from each PMC, and just call each of your parents' in turn, and then
override with the locally defined methods. Then none of the method
names would need to be exported. On the other hand, if we wanted to
use SUPER::method, we'd need to keep a copy of the table just before
overriding it with the locally defined methods.

Am I making sense? Andy's patch is definitely correct, but anyone want
to venture an opinion about namespace pollution?

> -  fprintf(stderr," *** size %d\n",key->size);
> +  fprintf(stderr," *** size " INTVAL_FMT "\n",key->size);

That's what I've been doing in my local copy, but is that portable? I
seem to remember that some preprocessors require strange tricks to
concatenate strings.

Reply via email to