DJ Delorie <d...@redhat.com> writes: >> 2) The parent class does not consist only of pure virtual methods. >> In that case I am arguing that all virtual methods should be >> protected. > > What about the case where the parent provides default implementations > of methods that are infrequently overridden by children? Otherwise, > you end up with cases where every child class needs to implement every > virtual method, whether it needs to for its own purposes or not. > > Your proposal forbids the case where a child is just like the parent, > "except that this method is a little different...", which describes a > lot of useful heirarchies. > > The gcc example would be the RTL base class defining RTL::reg_p() to > return false, and having the one class that is a reg redefine it to > return true. > >> The reason for the latter case is that the parent class is providing >> a public interface, and it is doing so by using a separate interface >> defined by child classes. The two interfaces are obviously related, > > Maybe you and I have completely different ideas about how the whole > class heirarchy works. I'm not a firm believer that the base-most > class should be an empty shell of a class that does nothing but > provide a placeholder for umpteen direct-but-leaf derived classes. A > base class is simply a more generic representation of data (and may be > derived from something even more generic), and derived classes are > more specific representations (and may be inherited by even more > specific representations). > >> there should be a public method which calls the protected method. > > I suggest this is arbitrary and unneeded. Having a foo_public() that > just calls foo_protected() is a waste of time (and means you have to > come up with two unique names for the same function), just move the > foo() into the public space.
I am advocating for a particular style, in which the parent interface is rigidly separated from the child interface. That style can of course accomodate the patterns you describe, and it does not require that base-most class be an empty shell. We don't have to adopt the style I'm advocating, but let's not turn it into a strawman. You can see examples of it in action in gold and in the gccgo frontend. In general I'm thinking about programming in the large. We want to adopt a style which permits GCC to continue to grow with different people understanding different parts of the compiler. We have learned over time that this requires rigid adherence to conventions in some cases. E.g., we never access tree or rtx fields directly, and when we've done it in the past we've been sorry. From this perspective, I think arguments about simplicity are the wrong arguments. The right arguments are the ones which say that I am recommending standards which are needlessly strict, and which will not help us in keeping the GCC code base maintainable over the years. Ian
