Don пишет: > Weed wrote: >> Don пишет: >>> Weed wrote: >>>> Don пишет: >>>>> Weed wrote: >>>>>> Frits van Bommel пишет: >>>>>>> Don wrote: >>>>>>>> Frits van Bommel wrote: >>>>>>>>> Don wrote: >>>>>>>>>> A straightforward first step would be to state in the spec that >>>>>>>>>> "the >>>>>>>>>> compiler is entitled to assume that X+=Y yields the same >>>>>>>>>> result as >>>>>>>>>> X=X+Y" >>>>>>>>> That doesn't hold for reference types, does it? >>>>>>>> I thought it does? Got any counter examples? >>>>>>> For any class type, with += modifying the object and + returning a >>>>>>> new one: >>>>>> The += operator too should return the object (usually "this") >>>>> ALWAYS 'this'. It's another feature of operator overloading which is >>>>> redundant. >>>> >>>> Not always. Can be more convenient to create the new object and to >>>> return it. >>>> >>>> For example: if it is necessary to return the object containing the >>>> sorted data those sorting hurriedly at creation of the returned object >>>> can give a scoring in performance than if the data is sorted in the >>>> current object after their change. >>> But then if you have >>> y = x+=b; >>> >>> surely that would give you x and y being different? >>> Wouldn't you want x to also point to the new object? (OK, as Stewart >>> pointed out, you can't!) Otherwise, you have to perform _both_ sorts! >> >> I agree, my point of view disputable. >> >> The programmer can have a desire to return not current object: the >> returned and this will be equivalent but are not identical. Do not >> forget that this object may be not a class - it can be struct and such >> return can in certain to save a few resources. >> But if us will force to return this under the threat of a compile error >> I will not cry.:) >> >> And you have certainly noticed that here the solution inaccuracy again >> appears to divide structures and classes by a principle "on value" and >> "reference". :) > > Yah. They're almost the same, but not quite. It's interesting that value > semantics are IMPOSSIBLE with classes (I didn't know that until > Stewart's post), whereas reference semantics with structs are possible > (but ugly) with structs. > > In my experience with D, I use structs + templates far more frequently > than classes + polymorphism. And I suspect that if interfaces were a bit > more powerful and efficient, struct+interface might replace even more of > the use cases for class-based run-time polymorphism. So I must admit, > I'm quite biased against classes.
I am absolutely agree with that that the interfaces too are necessary for structs. But whether you by means of templates and mixin repeat an OOP programming paradigm?
