Safer casts

[Yigal Chripun]

See my comments bellow.

Janice Caron wrote:
> On 11/05/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>> you miss the point.
> 
> I may be missing /a/ point, but I doubt I'm missing /the/ point. Who
> gets to decide what /the/ point is anyway? Is there even a "the" point
> to begin with?
> 
> 
>> it's not just a matter of syntax it's a matter of
>>  better design strategy.
> 
> Who gets to define "better"? Seems to me that Phobos has the better
> design strategy, but that's just personal opinion, with no more to
> back it up than yours. But still - the template strategy seems to
> offer /everything/ that polymorphism offers (including polymorphism),
> and more.
> 
> 
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? c++ certainly does not provide this
flexibility with STL.

> 
>>  Nothing stops me from using:
>>  array.sort(SwapStrategy.stable, dg);
> 
> Except that your interface must expose that function signature, which
> in turn means that all implementors of that interface must support
> that function. Interfaces cannot provide implementations, so although
> you could supply a mixin, there is no guarantee that all implementors
> will use it.

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.
another benefit is that each derived class can provide a specialized and
optimized version for its own internal structure. Iterators add overhead
here for no reason. oh there is one reason, generality... right?

> 
> 
>>  Also I do realize that since arrays are builtins they cannot implement
>>  interfaces. IMO, the best solution is to make all type behave like
>>  objects via syntax sugar. D is already half way there, since you can do
>>  int.max and such.
> 
> OK, so you propose adding new features to the language, just so that
> you don't have to use templates? The prevailing wisdom is, if it can
> be done with a library solution, it should; if not, then maybe we need
> new syntax. But we don't generally get new syntax just because some
> people don't like templates, so I suspect that that is unlikely to
> happen.
> 
actually, I'm talking about existing D features and Walter's plans to
enhance them which where announced in last year's conference. I'm merely
stating that those changes would be useful here, I didn't propose
anything new here.

> 
>>  My point is that I separate the interface exposed to the user ( the
>>  syntax of D) from the implementation.
> 
> So does std.algorithm.
> 
> std.algorithm provides container-independent,
> sort-criterion-independent, algorithms. Plug in container or
> sort-criterion of your choice. The container only needs to expose
> iterators, and all of std.algorithm's functions will work.

again, Iterators can be useful for some tasks, but they are inherently
limited. I've read an article once about that topic, if I can find it,
I'll post it here. the gist is that there are more general and better
solutions than iterators. C++ uses iterators extensively simply because
it has no other choice since it lacks the needed language support for
other approaches. fortunately, D does provide all the necessary language
support, so we are not limited by iterators any more. :)
> 
> 
>>  My mantra is: use the right tool for the job. That means that although
>>  templates are a useful tool, I don't think it's the only tool D provides
>>  that should be used to solve all problems.
>>  IMO, this problem is better solved with polymorphism and proper
>>  encapsulation.
> 
> Again, who gets to define "better"?