Derek Parnell wrote:
> On Tue, 10 Oct 2006 23:26:01 -0400, Jarrett Billingsley wrote:
> 
> 
>>"rm" <roel.mathys@gmail.com> wrote in message news:egh0bu$2155$1@digitaldaemon.com...
>>
>>>Lionello Lunesu wrote:
>>>
>>>>It's not a big deal, since I can use composition
>>>
>>>but mixin' it in, works nicely
>>
> 
> I know I'm just dreaming but it would be very nice-to-have if one could do
> this ...
> 
>  struct Color
>  {
>     ubyte Red;
>     ubyte Green;
>     ubyte Blue;
>  }
> 
>  struct Pixel extends Color
>  {
>      ubyte Alpha;
>  }
> 
>  Pixel Z
>  Z.Red = 80;
>  Z.Blue = 125;
>  Z.Green = 0;
>  Z.Alpha = 128;
> 
> rather than 
> 
>  struct Color
>  {
>     ubyte Red;
>     ubyte Green;
>     ubyte Blue;
>  }
> 
>  struct Pixel
>  {
>      Color color;
>      ubyte Alpha;
>  }
> 
>  Pixel Z
>  Z.color.Red = 80;
>  Z.color.Blue = 125;
>  Z.color.Green = 0;
>  Z.Alpha = 128;

This could of course be implemented in D. And I think it would be useful.

struct A
{
    somefield a;
}

struct B: A
{
    otherfield b;
}

And the compiler would simply slap the A fields at the beginning of B. Off-hand I don't see why this would be difficult to implement. But implementing this would cause demands for multiple inheritance.

struct A
{
    alpha a;
}
struct B
{
    beta b;
}
struct C: A B
{
    gamma c;
}

And all's well, except when folks start doing

struct D: B A
{
}
struct E: C D
{
}

Then what? Of course we could have a restriction that says all of the inherited fields must have unique names. This, admittedly arbitrary restriction could make usage and code clearer, and expunge ambiguities.

struct Frozen_Pizza: Comestible Consumable Perishable
{
}

At this point one might start wondering whether the pros outweigh the cost. (And the possible cons?) I don't have an opinion on this yet. But doing

struct Frozen_Pizza
{
    Comestible
    Consumable
    Perishable
}

might not be all too labourious in a real-world situation, after all? Except when we want to use polymorphism.

Frozen_Pizza fp = new Frozen_Pizza;
Perishable p = fp;
// insert the use-before dates in p

Implementing this without any tables would be nice. Just plain structs, and the compiler would simply create and manipulate the derived structs "as usual".

Georg Wrede wrote:
> 
> This could of course be implemented in D. And I think it would be useful.
> 
> struct A
> {
>     somefield a;
> }
> 
> struct B: A
> {
>     otherfield b;
> }
> 
> And the compiler would simply slap the A fields at the beginning of B. Off-hand I don't see why this would be difficult to implement. But implementing this would cause demands for multiple inheritance.
> 
> struct A
> {
>     alpha a;
> }
> struct B
> {
>     beta b;
> }
> struct C: A B
> {
>     gamma c;
> }
> 
> And all's well, except when folks start doing
> 
> struct D: B A
> {
> }
> struct E: C D
> {
> }
> 
The response to "demands for multiple inheritance" should simply be "No".

D doesn't support multiple inheritance for classes even, so it seems odd that it would go out of its way to allow it for structs.  I see nothing wrong with just saying structs can only do single inheritance.

--bb

On Mon, 16 Oct 2006 09:20:42 +0900, Bill Baxter wrote:

> The response to "demands for multiple inheritance" should simply be "No".
> 
> D doesn't support multiple inheritance for classes even, so it seems odd that it would go out of its way to allow it for structs.  I see nothing wrong with just saying structs can only do single inheritance.

And I'd go so far as to say that the term 'inheritance' is a bit strong. Maybe just 'derivation' as we would be deriving a new struct definition from existing definitions, but there is no implied linkage between them at runtime.

But this would have to be a 2.0 feature anyway as it is not a *required* language feature.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
16/10/2006 11:38:37 AM

Derek Parnell wrote:
> And I'd go so far as to say that the term 'inheritance' is a bit strong.
> Maybe just 'derivation' as we would be deriving a new struct definition
> from existing definitions, but there is no implied linkage between them at
> runtime. 

If it is just derived from that is wanted wouldn't it bee easier with a syntax like this.

struct foo
{
	int b;
	int c;
}
struct bar
{
	int a
	include foo;
	int d
}

the struct bar would now have four fields (a,b,c,d)

this way their is no way to misunderstand it for inheritance and if one want a foo* one can always take the addres of the first element.

On Mon, 16 Oct 2006 18:49:20 +0200, Johan Granberg wrote:

> Derek Parnell wrote:
>> And I'd go so far as to say that the term 'inheritance' is a bit strong. Maybe just 'derivation' as we would be deriving a new struct definition from existing definitions, but there is no implied linkage between them at runtime.
> 
> If it is just derived from that is wanted wouldn't it bee easier with a syntax like this.
> 
> struct foo
> {
> 	int b;
> 	int c;
> }
> struct bar
> {
> 	int a
> 	include foo;
> 	int d
> }
> 
> the struct bar would now have four fields (a,b,c,d)
> 
> this way their is no way to misunderstand it for inheritance and if one want a foo* one can always take the addres of the first element.

Hey ... not bad.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Derek Parnell wrote:
> On Mon, 16 Oct 2006 18:49:20 +0200, Johan Granberg wrote:
> 
>> Derek Parnell wrote:
>>> And I'd go so far as to say that the term 'inheritance' is a bit strong.
>>> Maybe just 'derivation' as we would be deriving a new struct definition
>>> from existing definitions, but there is no implied linkage between them at
>>> runtime. 
>> If it is just derived from that is wanted wouldn't it bee easier with a syntax like this.
>>
>> struct foo
>> {
>> 	int b;
>> 	int c;
>> }
>> struct bar
>> {
>> 	int a
>> 	include foo;
>> 	int d
>> }
>>
>> the struct bar would now have four fields (a,b,c,d)
>>
>> this way their is no way to misunderstand it for inheritance and if one want a foo* one can always take the addres of the first element.
> 
> Hey ... not bad. 
> 

By "first element" you mean "first foo element in bar"?

Isn't that just a mixin without the namespace?

Anyway, I thought the point of this was so that you could pass a bar* to a function that takes a foo*.  If foo is jammed in somewhere in the middle of bar then that's not so straightforward.  I guess the compiler could automatically offset the bar* to its foo part if it sees the bar* is being used in a foo* context.  But that seems kinda tricky to get right.

--bb

Bill Baxter wrote:
> Derek Parnell wrote:
>> On Mon, 16 Oct 2006 18:49:20 +0200, Johan Granberg wrote:
>>
>>> Derek Parnell wrote:
>>>> And I'd go so far as to say that the term 'inheritance' is a bit strong.
>>>> Maybe just 'derivation' as we would be deriving a new struct definition
>>>> from existing definitions, but there is no implied linkage between them at
>>>> runtime. 
>>> If it is just derived from that is wanted wouldn't it bee easier with a syntax like this.
>>>
>>> struct foo
>>> {
>>>     int b;
>>>     int c;
>>> }
>>> struct bar
>>> {
>>>     int a
>>>     include foo;
>>>     int d
>>> }
>>>
>>> the struct bar would now have four fields (a,b,c,d)
>>>
>>> this way their is no way to misunderstand it for inheritance and if one want a foo* one can always take the addres of the first element.
>>
>> Hey ... not bad.
> 
> By "first element" you mean "first foo element in bar"?
> 
> Isn't that just a mixin without the namespace?
> 
> Anyway, I thought the point of this was so that you could pass a bar* to a function that takes a foo*.  If foo is jammed in somewhere in the middle of bar then that's not so straightforward.  I guess the compiler could automatically offset the bar* to its foo part if it sees the bar* is being used in a foo* context.  But that seems kinda tricky to get right.
> 
> --bb

I you put foo first in bar that would work otherwise you would have to offset the address yourself.

Yes it is much like a mixin the difference is that you are mixing in a struct instead of a template.

Johan Granberg wrote:
> Derek Parnell wrote:
>> And I'd go so far as to say that the term 'inheritance' is a bit strong.
>> Maybe just 'derivation' as we would be deriving a new struct definition
>> from existing definitions, but there is no implied linkage between them at
>> runtime. 
> 
> If it is just derived from that is wanted wouldn't it bee easier with a syntax like this.
> 
> struct foo
> {
>     int b;
>     int c;
> }
> struct bar
> {
>     int a
>     include foo;
>     int d
> }
> 
> the struct bar would now have four fields (a,b,c,d)
> 
> this way their is no way to misunderstand it for inheritance and if one want a foo* one can always take the addres of the first element.

Good! Perhaps the keyword "mixin" could be (mis)used for this?

L.