Old problem with performance

Derek Parnell derek at psych.ward
Sun Feb 8 14:59:05 PST 2009


On Sun, 08 Feb 2009 14:37:18 -0800, Walter Bright wrote:

> Derek Parnell wrote:
>> On Sun, 08 Feb 2009 11:13:00 -0800, Walter Bright wrote:
>> 
>>> In particular, classes are *meant* to be used as reference types, but 
>>> the program is trying to treat them as value types. Virtual functions 
>>> are orthogonal to what value types are - a continuing problem C++ 
>>> programs have is conflating value types with reference types.
>> 
>> In D, what is the recommend technique to derive one user-defined value type
>> from another?
> 
> There isn't one. Deriving types only makes sense when expecting 
> polymorphic behavior, which is completely orthogonal to the whole idea 
> of a value type. A polymorphic type should be a reference type.

Thank you. I was using "derive" in the English language sense rather than
the O-O sense, but I get your point - for example a 'currency' value type
is only ever to be used as a currency value and not any of its base value
types.

Fair enough. 


> A value type can have *aggregation*, however, as in:
> 
> struct Sbase
> {
>      ... base members ...
> }
> 
> struct S
> {
>      Sbase base;
>      ... more members ...
> }
>
> You can also embed interfaces in a struct:
> 
> interface I { ... }
> struct S
> {
>      I i;
> }

This is what I thought too. In D, a value type can be derived from another
value type by using a combination of data aggregation (data inheritance if
you will) and interface aggregation (method inheritance?).

I feel that D could do with a little more syntax support for derived value
types though, because at times it is a bit awkward and/or verbose. I'll dig
up some examples of what I mean.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell



More information about the Digitalmars-d mailing list