|
Boost : |
From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-01-30 05:46:54
>From: "Terje Slettebø" <tslettebo_at_[hidden]>
> Given that supertype/subtype has such a general meaning, how should an
> is_super_and_subtype be defined? I guess the proposal mean to define it in
> terms of inheritance, only, and in that case, it would work like
> is_base_and_derived, with the addition that a type is its own
> supertype/subtype (but not its own base/derived type).
If we consider substitutability outside the class hierarchy, only (not
considering private/protected inheritance), then for is_super_and_subtype to
obey LSP, it should only give true in the case where an object or
pointer/reference of a type S is implicitly convertible to type T. This
means public, unambiguous base class, only. This is the way
is_base_and_derived works today, except that it doesn't give true for B = D.
However, for is_base_and_derived to really tell if something is base and
derived classes, it should ignore issues of access and ambiguity, which is
related to convertibility/substitutability, only, but not to whether or not
they are related by inheritance. In other words, it should give the semantic
that Rani's proposal has.
Whether or not the above semantic is desirable is another question. However,
if it is, to summarise, we could define these like this:
- Rename the current is_base_and_derived to is_super_and_subtype, and allow
it to give true for S = T.
- Use Rani's proposal for the new is_base_and_derived. Add specialisation to
give false for B = D.
There's also a question of existing code relying on the current semantics,
of is_base_and_derived giving false in the case of private/protected or
ambiguous base class. However, it may be argued that such code does not rely
on the stated documentation, so it's broken, anyway. Changing the
implementation of is_base_and_derived to use Rani's proposal still gives its
stated semantics, which is (from the docs):
is_base_and_derived<T,U>::value - Evaluates to true if type T is a base
class to type U.
It does not say "public, unambiguous base". That could be the wording for
is_super_and_subtype, instead.
Regards,
Terje
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk