Safer casts

[Janice Caron]

On 11/05/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
> I want to be able to do this:
>  List!(T) col = new LinkedList!(T);
>
>  and be able to change the linked list to a vector in the future (or any
>  other suitable collection) with the changes limited to this line alone.
>  is it possible with templates?

Umm. Yes.

    auto col = new LinkedList!(T);
    sort(col);

becomes

    auto col = new Vector!(T);
    sort(col);


> huh?
> the point of interfaces is to define relations so that I can be sure
> that I can sort all sortable collections for instance. the fact that
> it's in the interface dictates that all derived classes have to provide
> some way to do that. I don't care as a user how that is implemented, I
> just know I can sort my sortable collection since it's in the interface.

But ... what if it isn't? What if I import some.other.Collection which
doesn't support your interface? All of a sudden, my ability to sort
vanishes.

You can argue that that is entirely the fault of
some.other.Collection, for not implementing the interface, but come
on! If I want to create a collection, frankly, I just want to
implement the ability to put things in and get things out and store
things efficiently. I don't want to have to muck about re-inventing
the wheel by implementing stable sort, over and and over again for
each new collection.



>  another benefit is that each derived class can provide a specialized and
>  optimized version for its own internal structure. Iterators add overhead
>  here

No they don't. All they do is expose the ability to access the
collection, which you need to have anyway.


> for no reason. oh there is one reason, generality... right?

There are several reasons. Buglessness would be a good one, in my
eyes. I know that if I do

    sort(whatever)

using std.algorithm, then there will be no bugs, even if "whatever" is
a third-party collection. (That's assuming of course that
std.algorithm.sort has been thoroughly debugged, but with a standard
library one would certainly expect that). Whereas, if some
third-party-collection has reinvented the wheel and implemented their
own sort ... again ... well, that's just one more place for bugs to
creep in.

And of course, it's not just sort(). std.algorithm also provides
functions like reduce(), filter(), find(), count(), and a gazillion
more, all highly customizable. You want all of those in your container
interface, so that container implementors have to implement all of
them every time?

Frankly, it would be irresponsibility of a standard library /not/ to
provide reusable implementations.



>  fortunately, D does provide all the necessary language
>  support, so we are not limited by iterators any more.

Your use of language is prejudicial here. Note that I can substitute
anything I don't like into that sentence. For example: "Fortunately, D
does provide all the necessary language support, so we are not limited
by foreach any more", or "Fortunately, D does provide all the
necessary language support, so we are not limited by polymorphism any
more", or...

We are not limited, period. We have choices. Why not just say that?