Thread overview
Re: object oriented value type
Jul 02, 2007
Ender KaShae
Jul 12, 2007
Reiner Pope
Jul 13, 2007
BCS
Jul 13, 2007
Robert Fraser
July 02, 2007
From the replies to this thread I can see that my object oriented struct would be very difficult if not impossible to implement so I am suggesting the following instead:

1. either:
    a) a copy construtor [ this(classtype value) ] that is called durring assignment
   or b) opAssign can be used for the same class
2. ability to inherit from primative types
July 12, 2007
Ender KaShae wrote:
> From the replies to this thread I can see that my object oriented struct would be very difficult if not impossible to implement so I am suggesting the following instead:
> 
> 1. either:
>     a) a copy construtor [ this(classtype value) ] that is called durring assignment
>    or b) opAssign can be used for the same class
> 2. ability to inherit from primative types 
I'm not sure what's wrong with genuine struct inheritance -- but not for polymorphism, just for code reuse. This would just be syntactic sugar for template mixins. Instead of:

template impl
{
    int x;
    bool xEven() { return (x % 2) == 0; }
}

struct Foo
{
    mixin impl;
}

struct Bar
{
    mixin impl;
    int y;
}

(which currently works in D)

why not allow

struct Foo
{
    int x;
    bool xEven() { return (x % 2) == 0; }
}

struct Bar : Foo
{
    int y;
}

Actually, this could be implemented better than a wrapper for mixins, because you don't need the source-code available. The compiler could effectively convert the above snippet into

struct Bar
{
    private Foo __f;
    alias __f.x x;
    alias __f.xEven xEven;

    int y;
}

(Although those aliases don't currently work in D, I think they capture the idea.)


And primitive types work naturally as structs, so inheriting from them is fine as well.


 -- Reiner
July 13, 2007
Reply to Reiner,

> I'm not sure what's wrong with genuine struct inheritance -- but not
> for polymorphism, just for code reuse. This would just be syntactic
> sugar for template mixins. Instead of:
> 

This would even act more or less as expected if everything is implicitly un overrideable.

Cast to base type, OK (and implicit).
Cast to derived type, Do at your own risk (no null on bad cast).

> 
> And primitive types work naturally as structs, so inheriting from them
> is fine as well.

OOhhhh.  Cool. <g>

> 
> -- Reiner
> 


July 13, 2007
That is a _really_ good idea, and doesn't sound that hard to implement. votes++

Reiner Pope Wrote:

> Ender KaShae wrote:
> > From the replies to this thread I can see that my object oriented struct would be very difficult if not impossible to implement so I am suggesting the following instead:
> > 
> > 1. either:
> >     a) a copy construtor [ this(classtype value) ] that is called durring assignment
> >    or b) opAssign can be used for the same class
> > 2. ability to inherit from primative types
> I'm not sure what's wrong with genuine struct inheritance -- but not for polymorphism, just for code reuse. This would just be syntactic sugar for template mixins. Instead of:
> 
> template impl
> {
>      int x;
>      bool xEven() { return (x % 2) == 0; }
> }
> 
> struct Foo
> {
>      mixin impl;
> }
> 
> struct Bar
> {
>      mixin impl;
>      int y;
> }
> 
> (which currently works in D)
> 
> why not allow
> 
> struct Foo
> {
>      int x;
>      bool xEven() { return (x % 2) == 0; }
> }
> 
> struct Bar : Foo
> {
>      int y;
> }
> 
> Actually, this could be implemented better than a wrapper for mixins, because you don't need the source-code available. The compiler could effectively convert the above snippet into
> 
> struct Bar
> {
>      private Foo __f;
>      alias __f.x x;
>      alias __f.xEven xEven;
> 
>      int y;
> }
> 
> (Although those aliases don't currently work in D, I think they capture the idea.)
> 
> 
> And primitive types work naturally as structs, so inheriting from them is fine as well.
> 
> 
>   -- Reiner