On Fri, 31 Dec 2010 12:09:04 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 12/31/10 9:47 AM, Steven Schveighoffer wrote:
On Fri, 31 Dec 2010 10:35:19 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> 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
I thought I have clearly shown that that is the _common_ case.
Depends on what you are doing. If you are writing numerical types for
standard libraries, yes, it's common to have them, but you generally only
write them once. I'd say it's more common to add one or two operators to
custom types for syntax sugar than to implement all the math operators on
lots of types. But that's just my point of view. Either view is probably
too subjective to be "proof".
-Steve
