Walter's second axiom
Stewart Gordon
smjg_1998 at yahoo.com
Sat Dec 8 08:09:23 PST 2007
"Janice Caron" <caron800 at googlemail.com> wrote in message
news:mailman.271.1197121661.2338.digitalmars-d at puremagic.com...
> On 12/8/07, Stewart Gordon <smjg_1998 at yahoo.com> wrote:
>> S or MyInt should be a union rather than a struct. This is
>> because it doesn't make sense to add more member variables to the
>> derived type
>
> The axiom says struct.
But why? And where did Walter state this axiom? I can't seem to find it by
a quick search.
> Also, I don't necessarily agree that adding member variables would
> be a problem. The axiom says it should be /possible/ to create a
> wrapped type. It doesn't say it should /not/ be possible to create
> something with more data. (Implicit casting should fail for any
> narrowing conversion though).
It also doesn't, as far as you've put it, state anything about /how/ the
programmer would go about creating this wrapped type, with or without more
data.
>> (it would increase the size, thereby violating the 'is a'
>> principle of inheritance).
>
> Adding a union member is also capable of increasing the size.
True, but the point is that adding a member variable to a union is capable
of _not_ increasing its size, which is more than can be said of structs.
Indeed, a possible approach that stays within the 'is a' principle would be
to allow
union Qwert : Yuiop {
Asdfg hjkl;
}
as long as Asdfg.sizeof <= Yuiop.sizeof. That isn't to say it shouldn't be
possible to create wrapper types that increase the size, just that to do so
may require a different notation. Of course, with this different notation
the wrapper type wouldn't be implicitly convertible to its base type.
> Moreover, there is no such principle restricting inheritance. Those of
> us who come from a C++ background are quite au fait with stuff like
>
> // C++
> struct A { int x; };
> struct B : public A { int y; };
>
> where B inherits from A and simultaneously increases its size.
<snip>
Well, D isn't C++. Current uses of this colon notation in D follow the 'is
a' relationship exactly as I described in the thread I linked to. It might
be confusing if we add some uses of the notation that don't - or that may or
may not, depending on other factors.
Stewart.
--
My e-mail address is valid but not my primary mailbox. Please keep replies
on the 'group where everybody may benefit.
More information about the Digitalmars-d
mailing list