On Mon, 24 May 2010 12:06:18 -0400, Robert Jacques <[email protected]>
wrote:
On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer
<[email protected]> wrote:
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques <[email protected]>
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
<[email protected]> wrote:
[snip]
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one function is instantiated to copy data
from all the other containers. The problem with using generic code
is that the compiler will needlessly duplicate functions that are
identical.
This sounds like a failure of design. Why aren't you using ranges to
do this?
Why are ranges necessarily better? I'm using the container's opApply,
which I'd probably still use even if there were no interfaces. opApply
allows much more possibilities in traversal than ranges which cannot
use stack recursion without heap activity.
Ranges are not necessarily better and may have some minor amount of
overhead over a well optimized opApply. Then again, the opposite may be
true. The point is that if the difference between opApply and a range is
more than trivial, you've probably had a failure of design occur.
The difference is trivial. I support both ranges and opApply. The main
benefit from using opApply being only one function is compiled by the
compiler.
Using interfaces is not as viral as you think. My interfaces can be
used in generic code, as long as the generic code uses functions in
the interfaces. If a library returns an interface, the author is
saying "I don't want you using any functions outside this interface,"
so why is that a bad thing?
Well, needlessly duplicated functions for one. :) More importantly,
the example I gave was about third party libraries which I have no
control over. So this solution explicitly doesn't work. And even if
everyone used templates everywhere in order to be compatible with both
interfaces and classes, isn't that a viral effect of having both?
If a 3rd party library uses interfaces, it's probably for good reason.
They most likely want to remain binary compatible with other libs,
and/or want to abstract the implementation of some custom container
type. If you don't like their requirements, don't use the library.
-Steve
No, if a 3rd party library _needs_ to use interfaces it's probably for a
good reason. The problem is, if they exist, people are going to use them
even if they don't need them. Which therein lies the problem.
And if 3rd party X _needs_ to use interfaces, and 3rd party Y _needs_ to
use interfaces, and your code depends on X and Y, and interfaces aren't
defined by dcollections, where are you then? I don't think there's any
way you can define a generic standard library such that people won't
create bad designs, that's a lost cause.
I think part of the problem with all this is that interfaces aren't likely
to be needed any time soon (D's dynamic lib support is almost
non-existent), so I'm probably going to drop the interfaces for now in the
interest of progress.
-Steve
