Clay language

[Steven Schveighoffer]

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 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