Making inheritance less tedious

Sean Kelly sean at f4.ca
Tue Feb 27 12:13:25 PST 2007


Michiel wrote:
> Sean Kelly wrote:
> 
>>> 1) You cannot inherit constructors.
>> <SNIP>
>>
>> The new inherited behavior makes sense for Puppies, but not necessarily
>> for Aibos.  One might argue that a refactoring of the hierarchy is a
>> good idea here, or that Aibos aren't actually pets, but I think it's
>> reasonable to assume that because inheritance suggests specialization,
>> it may occasionally be desirable to place constraints on inherited
>> attributes.
> 
> I have to disagree here (partially).
> 
> If all Pets eat (specified by putting this behaviour/data in the Pet
> class) and an Aibo is a Pet (specified by inheriting from Pet, creating
> an is-a relationship), then Aibo's should also eat. If Aibo's do not
> eat, then either an Aibo is not a Pet, or Pets in general don't eat.

Yeah, it was a bad example.  I was really thinking more along the lines 
of constraints rather than hiding behavior altogether.  Maybe Dogs eat 
beef but snakes eat mice, but the property is stored in Animal because 
all animals eat.

> However, I understand your point. If a base class is changed, and you
> have no source-access to it, you still don't want to entirely break your
> subclass away from it. Maybe another type of relationship should be
> formally introduced for such situations. 'Is-kinda-like', or
> 'is-mutation-of' or something, which would allow suppressing parts of
> the public interface.

This is where I was getting at with refactoring the hierarchy, but that 
isn't always feasible.  I suppose an alternative would be to do as you 
say and specify exactly what traits are inherited, but I'm not sure if 
the added complexity is worth it.


Sean



More information about the Digitalmars-d mailing list