October 25, 2010
On 8/20/10 23:06 CDT, Shin Fujishiro wrote:
>> 2.  The base interface is OutputRange!(E).  If I change the base
>> interface to OutputRange!(E...), then OutputRange!(uint, double) won't
>> be a subtype of OutputRange!(uint).  This is self-evidently ridiculous.
>> I could maybe make OutputRangeObject!(E...) inherit from
>> OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but
>> other than nasty string mixins D doesn't provide a way to inherit from a
>> tuple of interfaces.
>
> Oh, really?  That's bad.  I thought tuples could be used in the class inheritance list.  IIRC something like the following also does not work due to a deep inheritance bug:
>
> interface OutputRange(E...) : OutputRange!(E[1 .. $]) {
>      void put(E[0] e);
> }
>
> Then, maybe we should put off supporting this anyway...

Once Kenji's adapt() is in place, this problem can be considered solved. I suggest we move with variadic OutputRange.

Andrei
October 25, 2010
I think this should be mentioned - the present solution is still imperfect because e.g. an OutputRange(int, float, string) is not a subtype of OutputRange(int, float). However, doing so would scale exponentially in the number of arguments...

Andrei

On 8/21/10 9:47 CDT, David Simcha wrote:
> Wow, you're right. You can implement a tuple of interfaces. When I wrote the last email saying you couldn't it was late at night in my time zone. I didn't bother double-checking because I had never seen such a thing documented or done before. I got your requested feature of implementing multiple output types working at the small cost of having to use a string mixin to write the put methods, since static foreach never made the cut. The latest revision is at http://pastebin.com/azM0Xnqh .
>
> On 8/21/2010 12:06 AM, Shin Fujishiro wrote:
>> David Simcha<dsimcha at gmail.com> wrote:
>>> Hmm. It's worth considering, but I see at least two problems.
>>>
>>> 1. Do we have a practical use case for it? I don't generally believe in adding complexity without clear use cases for said complexity.
>> I'm not sure. I/O-related ranges tend to have chunk-writing overloads:
>>
>> void put(E value);
>> void put(E[] chunk);
>>
>> And the Appender has a similar overload for bulk appending. But such ranges can work with only one of those overloads.
>>
>>
>>> 2. The base interface is OutputRange!(E). If I change the base
>>> interface to OutputRange!(E...), then OutputRange!(uint, double) won't
>>> be a subtype of OutputRange!(uint). This is self-evidently ridiculous.
>>> I could maybe make OutputRangeObject!(E...) inherit from
>>> OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but
>>> other than nasty string mixins D doesn't provide a way to inherit from a
>>> tuple of interfaces.
>> Oh, really? That's bad. I thought tuples could be used in the class inheritance list. IIRC something like the following also does not work due to a deep inheritance bug:
>>
>> interface OutputRange(E...) : OutputRange!(E[1 .. $]) {
>> void put(E[0] e);
>> }
>>
>> Then, maybe we should put off supporting this anyway...
>>
>>
>>> On 8/20/2010 9:26 PM, Shin Fujishiro wrote:
>>>> David Simcha<dsimcha at gmail.com> wrote:
>>>>
>>>>> In addition to the changes I made last night, I've also made the following changes:
>>>>>
>>>>> 1. Change name to inputRangeObject/InputRangeObject.
>>>>> 2. Add support for output ranges as
>>>>> outputRangeObject/OutputRangeObject.
>>>>> 3. Remove the now ridiculous looking Hungarian notation on the
>>>>> interfaces.
>>>>>
>>>>> http://pastebin.com/U83YNJfJ is where it's at.
>>>>>
>>>>> Any more comments from anyone, or does this look ready to be checked in?
>>>>>
>>>> Could you make OutputRangeObject able to accept multiple element types?
>>>>
>>>> template outputRangeObject(E...) {
>>>> auto outputRangeObject(R)(R range) { ... }
>>>> }
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
1 2
Next ›   Last »