Safer casts

Yigal Chripun yigal100 at gmail.com
Sun May 11 08:47:14 PDT 2008


Janice Caron wrote:
> 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);
> 
right...
and what about my function?
void WalkListAndDoSomething(List!(T) list);
 would become what?
void WalkListAndDoSomething(auto list);
I wonder if the compiler will accept that..
There is no such thing as List!(T) in the STL design. either you use a
vector or you use a linked list. there's nothing in between.

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

But you are re-inventing the wheel! the entire point is to have a
collection framework in the standard library. No one needs to write a
list in Java or C#. Those frameworks are built to be extend-able if you
in that much of a need of a different specialized collection. but than
again, if you are writing a new specialized version instead of using the
standard version that comes with the standard library than you would
want to implement your highly optimized sort function as well.
> 
> 
> 
>>  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.
the overhead here is a separate object, and function calls for the
iterator object. for most simple traversals, that's an unnecessary
overhead when I could just use the collection.each method with a
delegate like I can do in Ruby/Smalltalk/other high level languages than
don't force me to manually advance an iterator to the next object in the
collection. (yes, D does that for me with foreach, yet it is another
level of indirectness) Iterators are useful when I really want to
control myself the order of traversal or stuff like that. if I just want
to sum the values of all the objects in the collection, than an iterator
is an overhead. guess what kind of action is more common.
> 
> 
>> 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.

nothing has to be either/or. D provides many mechanisms such as mixins
for example that could be used. and the standard library can provide
general functions too. if I use the container in the standard library, I
can use the built-in collection.sort(); and if i use a third-party
collection, i could also use thirdPartyCollection.sort(); [that will use
the template solution and the proposed D2 extension for open classes,
I've mentioned a few times]
or if you prefer, sort(thirdPartyCollection);
besides, all those templates could double-up as code the collection
writers can mix-in into their collection classes to implement the
interfaces. this way, a third party vendor can decide to be compatible
to the D standard library and implement all those interfaces with the
provided mixins, and in case his collection isn't compatible the user
could use the same templates himself.
that's a win-win situation.


> 
> 
> 
>>  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?
I just did, didn't I? the point was comaring to C++ where those choices
aren't available or if they are they are much harder to accomplish.



More information about the Digitalmars-d mailing list