On Fri, 31 Dec 2010 10:35:19 -0500, Andrei Alexandrescu
<[email protected]> wrote:
On 12/31/10 9:32 AM, Andrei Alexandrescu wrote:
On 12/31/10 7:30 AM, "Jérôme M. Berger" wrote:
Andrei Alexandrescu wrote:
And I stand by that claim. One aspect that seems to have been
forgotten
is that types usually implement either op= in terms of op or vice
versa.
That savings alone is large.
This could have been done with a couple of stdlib mixins
"generateOpsFromOpAssign" and "generateOpAssignsFromOp".
The language definition would have stayed just as large.
Andrei
Besides, I feel a double standard here. Why are mixins bad for
simplifying certain rarely-needed boilerplate, yet are just fine when
they supplant a poor design?
Requiring mixins in any case looks like a poor design to me. Any time
mixins are the answer, it raises significantly the bar for understanding
not only how to write the code, but how to use it as well. Mixins are
great for low-level things that can be abstracted away, but to make them
part of your interface looks to me like we're back to C macros. Anyone
trying to follow the code is going to have to jump through quite a few
hoops to understand it.
I think the point of Jerome is that the uncommon case of wanting to
specify multiple operators with one template could have been solved with
mixins (which would be abstracted as implementation details), and then the
benefits we had with the old scheme (simple to understand and write,
automatically virtual, allow covariance, etc.) would not be delegated to
obscure library or compiler tricks.
Where the old scheme breaks down is the whole opIndexAddAssignXYZ mess.
It doesn't matter anyways, we have what we have. Let's just try and fix
the blocker problems (such as no templates in interfaces) and see how we
fare.
-Steve
