Making inheritance less tedious

[Michiel]

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.

Ok, ok. I realise that this may be nothing more than my personal
programming philosophy. But it makes sense. If you are allowed to
randomly disregard parts of the public interface from a base class, then
the is-a relationship no longer really holds, and you couldn't give an
Aibo to a function that asks for a Pet (and might try to feed it).

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.

-- 
Michiel