On Mon, 24 May 2010 17:11:49 -0400, Walter Bright
<[email protected]> wrote:
Steven Schveighoffer wrote:
It's a logical conclusion. You provide a map-type collection, call it
a HashMap. Then, a UI designer wants to abstract his specific Map-like
container that exposes his elements, so you provide him a Map
interface. But HashMap implements all the required functions to be
able to implement the Map interface, so you slap Map on the back of the
class definition, and presto! It implements the map interface.
Where's the extra complexity?
The extra complexity is in the container supporting very different ways
to do the same thing.
I don't see this being "very different":
coll.add(coll2); // uses coll2 as interface.
coll.add(coll2[0..5]); // uses coll2 slice as a range.
coll.add(arr); // adds an array.
I don't see how that's a bad thing.
If the user wants an interface, he can add one on to the front of the
collection. It doesn't need to be in the collection itself.
We're going in circles here. I feel like pointing back to my previous
post with the wrapping example...
All an interface does is give an abstract representation of functions that
are *already there*. Removing the interface does not remove the functions
that implemented the interface.
The "bad" thing is the component integrating in capability that is
easily done as an add-on.
This reminds me of a fellow I worked with years ago who would provide
both a free-function interface and a class interface to each of his
components. It was completely redundant to do both, and added pages of
complexity and documentation.
This is completely different, I'm tacking on one small piece of
declaration and the class becomes an interface. I'm not reimplementing or
wrapping anything. Surely you can see that.
In a related story, I *did* have to do something like this when someone
wanted a Java interface to some C++ code we had. In order to do this, we
had to declare extern "C" functions that Java could interface via JNI.
-Steve
