Safer casts

[Janice Caron]

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.



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


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


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


>  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"?