December 31, 2010
Steven Schveighoffer <schveiguy@yahoo.com> wrote:

>> We thus see that the template this parameter has absolutely no value.
>
> No, it does have value:
[snip]
> Hey, look! covariance with templates :)

Ah, yes indeed. It seems I have misunderstood the purpose of the feature.

-- 
Simen
December 31, 2010
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
December 31, 2010
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?

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

Andrei
December 31, 2010
On Fri, 31 Dec 2010 12:09:04 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@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@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
1 2 3 4 5 6 7 8 9
Next ›   Last »