www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why can't I inherit (extend) structs?

reply Lionello Lunesu <lio lunesu.remove.com> writes:
I like the definition of 'struct' in D: simple aggregations of data. But 
is there currently a way to extend a struct? Apart from composition, 
that is. I'd like to do something like this:

struct X {
   int x;
}
	
struct Z : X {
   int z;
}

Would this feature add complications that I fail to see?

It's not a big deal, since I can use composition, but I'll have to name 
a member for the first struct and repeatedly write it.. And I'm lazy :S

L.
Oct 10 2006
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Lionello Lunesu wrote:
 I like the definition of 'struct' in D: simple aggregations of data. But 
 is there currently a way to extend a struct? Apart from composition, 
 that is. I'd like to do something like this:
 
 struct X {
   int x;
 }
     
 struct Z : X {
   int z;
 }
 
 Would this feature add complications that I fail to see?
 
 It's not a big deal, since I can use composition, but I'll have to name 
 a member for the first struct and repeatedly write it.. And I'm lazy :S
 

Once you start extending structs, you'll need the same bookkeeping overhead required for classes. That eliminates the current distinction between them.
Oct 10 2006
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:eggji8$1kih$1 digitaldaemon.com...
 Lionello Lunesu wrote:
 I like the definition of 'struct' in D: simple aggregations of data. But 
 is there currently a way to extend a struct? Apart from composition, that 
 is. I'd like to do something like this:

 struct X {
   int x;
 }
     struct Z : X {
   int z;
 }

 Would this feature add complications that I fail to see?

 It's not a big deal, since I can use composition, but I'll have to name a 
 member for the first struct and repeatedly write it.. And I'm lazy :S

Once you start extending structs, you'll need the same bookkeeping overhead required for classes. That eliminates the current distinction between them.

I don't need polymorphism and all that, just to add fields to an existing struct, like Derek's example: struct ColorRGB and then a struct ColorRGBA, which adds a field for the alpha (=transparency). Seems I can use mixins for this, at the moment. But there's shouldn't be extra bookkeeping. It should be like composition; like adding a nameless instance of the 'base' struct as the first member in the derived struct. L.
Oct 10 2006
prev sibling parent reply rm <roel.mathys gmail.com> writes:
Lionello Lunesu wrote:
 It's not a big deal, since I can use composition

but mixin' it in, works nicely rm ========================================= private import std.stdio; template XT() { struct { int x; } } struct X { mixin XT; } struct Z { mixin XT; int z; } void main() { X x; x.x = 5; writefln(x.x); Z z; z.x = 1; z.z = 2; writefln(z.x,' ',z.z); }
Oct 10 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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

Then you have to make sure to mix in the correct base structs in the correct order, and you still don't get type polymorphism (i.e. you can't have a pointer to a Base struct point to a Derived struct; you have to write Base* b = cast(Base*)derived;). Not to mention the sheer pain in the behind of managing a struct and its matching "members" template. It seems far more intuitive to be able to write ------- struct Base { int x; } struct Derived : Base { int y; } ------- Than ------- template BaseMembers() { int x; } struct Base { mixin BaseMembers; } template DerivedMembers() { int y; } struct Derived { mixin BaseMembers; mixin DerivedMembers; } ------- Technically in this example you don't need to have DerivedMembers, but if you wanted to derive from Derived, you'd have to.
Oct 10 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
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; -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 11/10/2006 2:18:29 PM
Oct 10 2006
next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Derek Parnell" <derek nomail.afraid.org> wrote in message 
news:ck4ro83hyjuv.1npxvrwohfkgk.dlg 40tude.net...
 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 ...

<snip> That's exactly what I want to be able to do, too! L.
Oct 10 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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".
Oct 14 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
 {
 }
 

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
Oct 15 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Oct 15 2006
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
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.
Oct 16 2006
next sibling parent reply Derek Parnell <derek psyc.ward> writes:
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!"
Oct 16 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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. 

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
Oct 16 2006
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
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. 

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.
Oct 16 2006
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Oct 16 2006
prev sibling parent reply rm <roel.mathys gmail.com> writes:
Jarrett Billingsley wrote:
 
 Then you have to make sure to mix in the correct base structs in the correct 
 order

why do you say correct order? when mixin in 2 structs with the same-named member, the first time I reference that member in the new struct, the thing won't compile any more? rm ========================================================= private import std.stdio; template XT() { struct { int x; } } template YT() { struct { int x; } } struct X { mixin XT; } struct Z { mixin XT; mixin YT; int z; } void main() { X x; x.x = 5; writefln(x.x); Z z; z.x = 1; z.z = 2; writefln(z.x,' ',z.z); }
Oct 11 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"rm" <roel.mathys gmail.com> wrote in message 
news:egj6fb$1ih4$1 digitaldaemon.com...

 why do you say correct order?

It matters when you're dealing with system libraries that expect structures to be laid out in a certain way, and it matters if you want to have type polymorphism (i.e. casting a pointer to a derived structure to a base structure type). I.e. template BaseMembers() { int x; } template DerivedMembers() { int y; } struct Base { mixin BaseMembers; } struct Derived { mixin DerivedMembers; // oops! wrong order mixin BaseMembers; } void main() { Derived d; d.x = 3; d.y = 4; Base* b = cast(Base*)&d; writefln(b.x); // prints "4", not "3" } The compiler can't complain about something like this because it doesn't know anything about deriving structs and keeping their members in the correct order in memory. With the ability to derive structs, the problem just goes away.
Oct 11 2006
prev sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"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

<snip> Good idea.. I'll try that.. L.
Oct 10 2006