Re: Thoughts on Gengtype and Single Inheritance

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Aug 24, 2012 at 10:06 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> To take full advantage of the conversion to C++, we will need to use

I'm not sure what "full advantage" of single-inheritance vs. composition is.

> single inheritance in some of our garbage collected structures.  To
> that end, we need to make gengtype understand single inheritance.
> Here are my thoughts on how to make that happen.
>
> There are two major sections, one for non-polymorphic classes and one
> for polymorphic classes.  Each section has a series of subsection
> pairs describing a new grammar and its implementation.
>
>
> NON-POLYMORPHIC CLASSES
>
> The classes we care about are polymorphic in the general sense,
> but not in the language sense, because they don't have virtual
> members or bases.  That is, they use ad-hoc polymorphism via an enum
> discriminator to control casting.
>
> enum E { EA, EB, EC, ED, EE };
>
>
> GRAMMAR
>
> The root class class must have a discriminator.
>
> class ATYPE GTY ((desc ("%h.type")))
> { public: enum E type; other *pa; ... };
>
> No derived class may have a discriminator.
>
> Every allocatable class must have a tag.
>
> class BTYPE : GTY ((tag ("EB"))) public ATYPE
> { public: other *pb; ... };
>
> The root class may be allocatable, and so may have a tag.
>
> class ATYPE GTY ((desc ("%h.type"), tag ("EA")))
> { public: enum E type; other *pa; ... };
>
> Two derived classes may share a base, even indirectly, but be
> otherwise unrelated.
>
> class CTYPE : GTY ((tag ("EC"))) public BTYPE { ... };
> class DTYPE : GTY ((tag ("ED"))) public BTYPE { ... };
> class ETYPE : GTY ((tag ("EE"))) public ATYPE { ... };
>
> Note the difference between C and D are siblings but D and E are
> siblings once removed (i.e. nephew and uncle).
>
> Private and protected fields are not supported, at least for those
> fields that gengtype cares about.

I see you are targeting 'tree' ... that's not the very best thing to
work on IMHO.

> IMPLEMENTATION
>
> We can probably hack into the existing generation for unions.
> However, there is a naming problem.  The current gcc union approach
> creates a "top type" for every class hierarchy.  A single-inheritance
> class hierarchy has no "top type" and so we cannot use it to name the
> marker.  We can use the base type, (aka "bottom type").
>
> That is, generate gt_ggc_mx_ATYPE full of a switch statement covering
> all known deriviations.  Any gt_ggc_mx names for derived types would
> be simply aliased to the base.

I thought we agreed to switch gengtype to fully use overloads of a signle
'mark' function instead of its weird internal mangling.  That also make it
less/un-necessary for it to understand types, it only needs to be able to
parse field identifiers (or in the inheritance case, base types (ugh)).

Though I'd simply declare that structures as complicated as tree need
manually implemented mark()ers.

Remove code from gengype!  Do not make it more complicated.

Think of how you'd implement explicit garbage collection in C++ from scratch,
without the help of something external such as gengtype.

Richard.