On 12/8/07, Janice Caron <caron800@googlemail.com> wrote:
> As discussed elsewhere, Walter's second axiom states: for any type T, it should be possible to construct a struct S which behaves exactly like a T

I would like to see this axiom turned into a language feature, so that one could write

    struct S : T {}

to create a struct S which behaves exactly like a T. For example

    struct MyInt : int
    {
        /* extra functions */
    }

which would be equivalent to

    struct MyInt
    {
        int n;
        /* forwarding functions */
        /* extra functions */
    }

That would just be so cool.

Janice Caron wrote:
> On 12/8/07, Janice Caron <caron800@googlemail.com> wrote:
>> As discussed elsewhere, Walter's second axiom states: for any type T,
>> it should be possible to construct a struct S which behaves exactly
>> like a T
> 
> I would like to see this axiom turned into a language feature, so that
> one could write
> 
>     struct S : T {}
> 
> to create a struct S which behaves exactly like a T. For example
> 
>     struct MyInt : int
>     {
>         /* extra functions */
>     }
> 
> which would be equivalent to
> 
>     struct MyInt
>     {
>         int n;
>         /* forwarding functions */
>         /* extra functions */
>     }
> 
> That would just be so cool.

Yes that would very neat.
I think about that every time I have to write a struct or class that I want to be array-like.  You have to try and thing of all the things that you can do on an array and implement those.  And don't forget all four flavors of opApply!  (fwd, fwd with counter, bkwd, bkwd with counter) [Do we have to make that 12 flavors with const/invariant now?]

I think the idea, though is that other language features will eventually be able to accomplish this. are going to be able to do this.  So for instance you could have something like

    struct MyInt {
        mixin Implements!(int);
    }

The thing that's not clear to me with that is how you leave out parts of the interface that you don't want and override others.  Maybe it does require new syntax.

--bb

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.270.1197118522.2338.digitalmars-d@puremagic.com...
<snip>
>    struct S : T {}
>
> to create a struct S which behaves exactly like a T. For example
>
>    struct MyInt : int
>    {
>        /* extra functions */
>    }
<snip>

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 (it would increase the size, thereby violating the 'is a' principle of inheritance).  However, it does make sense to add more views of the data, which is a common use of unions.

I briefly mentioned it here:
http://www.digitalmars.com/d/archives/digitalmars/D/42035.html#N42048

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

On 12/8/07, Stewart Gordon <smjg_1998@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.

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
> would increase the size, thereby violating the 'is a' principle of
> inheritance).

Adding a union member is also capable of increasing the size.

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.


> However, it does make sense to add more views of the data,
> which is a common use of unions. I briefly mentioned it here:
> http://www.digitalmars.com/d/archives/digitalmars/D/42035.html#N42048

I think either a struct /or/ a union should be allowed, depending on the programmer's preference.

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.271.1197121661.2338.digitalmars-d@puremagic.com...
> On 12/8/07, Stewart Gordon <smjg_1998@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. 

On 12/8/07, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> where did Walter state this axiom?  I can't seem to find it by a quick search.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=63309