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:
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
>
> Does that make sense?
>
> -Steve
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it needlessly expands the radius of comprehension
needed to understand and use the library. (See Tangled up in tools
http://www.pragprog.com/magazines/2010-04/tangled-up-in-tools) Second,
I
think designing a library to be flexible enough to meet some future,
anticipated need (e.g. dlls) is a good idea, but actually implementing
vaporous future needs is fraught with peril; it's too easy to guess
wrong.
Third, interface base design is viral; If library X uses interfaces
then I
have to use interfaces to interface with it. And if another library Y
uses
classes, then I'm going have to write a (needless) wrapper around one
of
them.
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.
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
