Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 18:22:55 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Needless to say, I'd be very curious to hear other opinions in this
matter. Please speak up - the future of D depends, in small part, on
this too.
As you know, you and I disagree on some aspects of containers. However,
I think our philosophies are converging.
[snip]
To summarize my understanding of your points:
(a) When you only want to tweak a container's behavior in small ways,
inheritance is great.
(b) Pass by reference is more natural for containers than pass by value.
(c) Proprietary code hiding is better with interfaces.
(d) Dynamically-linked code works best with interfaces.
(e) Interface-based code requires less recompilation and may save on
generated code.
(f) Interfaces simplify understanding.
At the same time, you argue that ranges aren't fit as interfaces because:
(a) Inlinining is difficult/impossible
(b) Value semantics is more natural for ranges
(c) I didn't understand this because you changed the subject from ranges
back to containers:
I also think functions that can be tuned to each
implementation should be. For this reason, dcollections containers
provide a lot of functionality that is not included in the interfaces,
simply because the functions are so specific to the implementation, it
would be the only class that implemented that interface. For example,
all the functions that return cursors (and soon ranges) are not
interface functions. This doesn't make them useless via interfaces, but
you cannot use every aspect of the container via an interface. An
interface is like a common denominator, and I think it should be useful
for some purposes. If nobody will ever use the interface as a parameter
to a function, then there is no point in declaring the interface (I
realize that I have created such interfaces in dcollections and I plan
to correct that -- one nice benefit of the contemplation triggered by
this discussion).
One other thing I'm worried about, and was an absolute pain in my
preliminary tests of container implementations, is this issue of
"iterators/ranges/cursors are not part of the container interface". It
is absolutely fundamental that you can get an abstract range from an
abstract container because most of what you can do to a container you
must do with ranges. Otherwise the duplication of functionality is
horrid. This failure alone is a reason to abandon the container
hierarchy design.
I am working on updating dcollections as we post, and I think I have
come up with a nifty way to do ranges that will both retain the
usefulness of the cursor, and provide a common way to plug the
collections into std.algorithm.
Good luck with your containers, I still hold out hope that dcollections
can be integrated in Phobos, but I probably need to get it working in
order to have any chance of competing :)
Good luck to you too. As I specified in my private message - if you undo
the fundamental mistake of making find()/contains() part of the
container (and of course all other disastrous mistakes of that kind),
then I'm sure dcollections will be a very solid library.
Andrei
