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.
But there's an interesting question: using opDot() and mixins, how close
can you come to implementing classes?
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.
Sounds like you want one struct + multiple interfaces.
