Steven Schveighoffer wrote:
On Mon, 24 May 2010 14:36:57 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
and on point 3, why is it not OK to *also* provide interfaces in
addition to ranges as dcollections does? That is, take away
dcollections' interfaces, and you have essentially compile-time
polymorphism, they all support ranges etc. Interfaces are also there
in case you want to use them in things like runtime plugin interfaces.
The best reason I can think of is to avoid kitchen-sink style
components. Components should do one thing well. Adding capability
should be done with aggregation by the user.
What if it can do both things well (I would propose that dcollections
does)?
Probably for the same reason I don't want a microwave built in to my TV set.
It's not a question of can it do both well, it's a question of is it a distinct
component or not.
Sure, but I'd argue that adding such runtime polymorphism should be
done with a separate add-on component. It should not be part of the
collection component.
So I should specifically have to wrap a collection type in order to make
it runtime polymorphic, forwarding all the operations to the
collection? Essentially something like:
class WrappedSet(Impl, V) : Set!V
{
Impl!V impl;
bool contains(V v) { return impl.contains(v);}
...
}
For what reason? Why is it so bad to just stick Set!V on the end of the
implementation class?
Because then everyone who just wants a hash table winds up carrying around the
complexity for things they don't want. The idea behind pluggable components is
that each component should be minimal, and then the user aggregates them to meet
his needs.
Also, much of a user interface consists of various collections
(listview, treeview, child widgets, etc.). Why is runtime
polymorphism good there, but not on a generic collections package
(not as the only means of access of course)?
A user interface object is not a collection component, I think there's
a confusion in the design there.
Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data?
That's up to the UI interface designer. It has nothing to do with how it
implements the collection under the hood.
For example, a .NET
ListView control contains an Items property which you can use to access
the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
A graphical component can wrap a collection component. I see no reason why the
collection needs to have runtime polymorphism to enable that.
