Safer casts

[Yigal Chripun]

Janice Caron wrote:
> On 11/05/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>>  for each different comp function there will be a different sort instance
>>  created by the compiler.
> 
> But surely, every container must itself be templatised on the element?
> I mean, unless you go the Java way and /only/ have a container for
> Objects. So your plan would instantiate at least one sort function for
> every element type.
> 
> Moreover, since your OrderedCollection interface would demand that
> every container must implement sort, then every different kind of
> collection would have it's own sort function.
> 
> So under your scheme, the total number of sort functions would equal
> the total number of container types. In other word, if your program
> used
> 
>     List!(char) list1, list2;
>     List!(int) list3;
>     List!(C) list4, list5;
>     Array!(double) array1;
> 
> then there would be four sort functions. In what way is that fewer
> than would be produced by
> 
>     sort(list1);
>     sort(list2);
>     sort(list3);
>     sort(list4);
>     sort(list5);
>     sort(array1);
> 
> ? The way I see it, we both get four. However, if choose /not/ to sort
> list3, then I only get three instantiations, but you still get four.
> 
> 
> 
> 
>>  What i'm trying to say is that using any one tool for
>>  everything is wrong.
> 
> You should have just said that to start with, because it's a statement
> of the obvious and no one will disagree with you. :-)
> 
> 
>>  I'm not arguing that delegates should replace all
>>  template code in D! I'm arguing that both solutions need to be evaluated
>>  and the better one chosen
> 
> Why are you assuming that that didn't happen?
> 
> 
>>  also note that these two options overlap
>>  sometimes and (when it's suitable) both solutions should be provided so
>>  the user could choose his preferred trade-off (time vs. memory).
> 
> Except that, if you can trivially create one from the other, then
> providing one is effectively providing both anyway.

>From what I know, an efficient STL implementation would use C style
containers with void* under the hood to minimize executable bloat.
in a perfect world, my idealized container collection would do something
similar. the interfaces need to use templates so that I have a list!(T)
and such with a proper hierarchy, however under the hood all those
List!(T) with different T types will use the same code. also, My
idealized collection framework would use mixins extensively to share
common code.
so, if all those tools are combined properly, the amount of sort
instances should be minimal.
the Java way is the extreme opposite of the c++ way, I want something in
the middle, Eiffel has the best design IMO, couple that API with C
efficiency and we got a winner :)
the idea is of course take the best from each language and combine it to
something even better.
BTW, you really should take a look at Eiffel. for example, it has
multiple-inheritance implemented in a completely different way than C++
avoiding most of c++ problems with it. they have many novel ideas there
that D can and should learn from.

My perfect collection framework would be based on the Eiffel design,
avoiding problems in the Java model and problems in the C++ model.

--yigal