Clay language

[Steven Schveighoffer]

On Fri, 31 Dec 2010 12:09:04 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 12/31/10 9:47 AM, Steven Schveighoffer wrote:
>> On Fri, 31 Dec 2010 10:35:19 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at 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