October 14, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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".
|
October 16, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Georg Wrede | 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
|
October 16, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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 |
October 16, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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.
|
October 16, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Granberg | 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!" |
October 16, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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
|
October 17, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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.
|
October 17, 2006 Re: Why can't I inherit (extend) structs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Granberg | 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.
|
Copyright © 1999-2021 by the D Language Foundation