Operator overloading -- lets collect some use cases

[Weed]

Don пишет:
> Weed wrote:
>> 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?
> 
> I generally use compile-time polymorphism rather than run-time.

What difference between them? vtable?

> But there's an interesting question: using opDot() and mixins, how close
> can you come to implementing classes?

All of us have already come! :)

In that example with matrices
(http://www.dsource.org/projects/openmeshd/browser/trunk/LinAlg/linalg/MatrixT.d,
template MultReturnType (ArgT)) the returned type of matrices needed to
be altered in void (in the pointer on void). And add check by list on
types to make the general for all matrices and other structs (vectors
etc.) in compile time. That is to imitate a base virtual class.
As a whole so, but I am did not check it.

If the present support vtable that is necessary I think it too it is
possible to make, I do not see any problems. But if you do not tell that
it is bad design that I will be surprised.

> A particularly interesting case is the GoF Strategy pattern, where
> derived classes add no data, they only override virtual functions.
> The slicing problem never happens with such objects, provided that you
> include the vtable pointer when you copy the object.

It is possible also real OOP to imitate not much more difficult

> Sounds like you want one struct + multiple interfaces.

I not against. Really, if the structure has methods that can have and
the interface (and interfaces can be inherited), it is logical.
As well compile-time inheriting could be made. To write so:

struct RGB {
    ubyte r;
    ubyte g;
    ubyte b;
}

struct RGBA : RGB {
    ubyte a;
}

such code is quite clear. But without them it is possible to live.

Much more important old kind classes on value, without them it is
impossible apparently.