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