Am 15.03.2011 21:07, schrieb Jens: > Daniel Gibson wrote: >> Am 15.03.2011 20:40, schrieb Jens: >>> Daniel Gibson wrote: >>>> Am 15.03.2011 20:24, schrieb Jens: >>>>> Daniel Gibson wrote: >>>>>> Am 15.03.2011 19:48, schrieb Jens: >>>>>>> Andrei Alexandrescu wrote: >>>>>>>> On 3/15/11 12:55 PM, Jens wrote: >>>>>>>>> Steven Schveighoffer wrote: >>>>>>>>>> That's all there is. Structs do not have inheritance, only >>>>>>>>>> alias this. >>>>>>>>> >>>>>>>>> Why don't they though? Inheritance does not have to mean >>>>>>>>> polymorphic. It can mean composition, like in C++. I don't >>>>>>>>> understand the reason for such ugly syntax. >>>>>>>> >>>>>>>> Using inheritance for composition is frowned upon in C++ for >>>>>>>> good reasons. If you want composition, the best is to use >>>>>>>> composition. >>>>>>> >>>>>>> It was frowned upon early on because the compiler implementers >>>>>>> didn't have their acts together and the resulting objects layout >>>>>>> could not be relied upon. The example I gave came from the STL so >>>>>>> I think "frowned upon" is something you are picking up from long >>>>>>> ago. >>>>>>> >>>>>>> Composition means access through the members rather than direct >>>>>>> access: >>>>>>> >>>>>>> struct point >>>>>>> { >>>>>>> int x; >>>>>>> int y; >>>>>>> }; >>>>>>> >>>>>>> struct point3d >>>>>>> { >>>>>>> point pt; >>>>>>> int z; >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> point3d mypoint; >>>>>>> mypoint.pt.x = 3; // ugly >>>>>>> >>>>>> >>>>>> This is why you add "alias pt this;" to point3d. So you can write >>>>>> mypoint.x = 3; >>>>>> >>>>> >>>>> Still ugly though. >>>>> >>>> >>>> I don't think so. It makes obvious what happens: a composition - >>>> *not* an inheritance - with syntactic sugar that allows one to omit >>>> the .pt in mypoint.(pt.)x - as long as mypoint doesn't have a member >>>> x itself. >>>> >>> >>> YMMV. To me it's ugly enough to not take the language seriously. >>> >>>> Allowing inheritance syntax on structs would only lead to confusion >>>> - especially for people coming from C++. >>>> >>> >>> C++ does it that way, so what confusion are you talking about? >>> >> >> The confusion that in C++ classes and structs are basically the same >> (only the default visibility of members is different) while in D >> they're not. >> So allowing "inheritance" on structs would give the false impression >> that structs in D are also classes of some kind. > > Not a good reason to change the syntax. That's what the manual is for. > What you said was: "Someone is going to try to program in D without > reading the manual and then be surprised when it doesn't work like C++ so > we'll just remove the construct so that doesn't happen -- at the expense > of elegant syntax". > >> >> Furthermore I find C++'s class handling quite unfortunate.. > > Me too, some of it. > >> only >> having polymorphism when explicitly using pointers really sucks. > > How is it different in D where all polymorphic objects are reference > types? Take have the design space away, make everything a glorified > pointer and things are better?
They obviously are. Successful languages like Java and C# do it. It's less error-prone and you don't have to worry about dereferencing stuff all the time (sometimes even multiple dereferences at once, like in my example). > >> e.g. you have a base class Foo and a class Bar derived from Foo.. now >> you wanna put Objects of type Foo and Bar in a list.. what do you do? > > We'll have to save container design for another day. >