Containers

[Russel Winder via Digitalmars-d]

On Fri, 2015-09-04 at 22:21 +0000, bitwise via Digitalmars-d wrote:
> 
[…]
> This is another problem:
>    "Containers do not form a class hierarchy, instead they 
> implement a common set of primitives (see table below). These 
> primitives each guarantee a specific worst case complexity and 
> thus allow generic code to be written independently of the 
> container implementation."
> 
> I believe this is wrong, in that the point of abstraction should 
> be the Ranges you get from the containers, not the containers 
> themselves. I think it's a little silly for an Array(T) to have a 
> "removeAny()" method.
> 
> 
[…]

I think I am missing a step in the argument here: if the point is that
Ranges are the core of the abstraction, why does there need to be a
class inheritance hierarchy. The lessons from C++, Java, Python, and
Go, include that the obsession with inheritance during the 1990s went
far too far. Inheritance can be useful, but for frameworks it is only
conformance to interfaces that matters for consistency across the
framework. Thus as long as every data structure type conforms to the
correct interface so that there is composability in the use of Ranges, 
then things are fine.

This though is philosophy and far too general. To continue this aspect
of the debate we would need to deal in more specific things. Are there
some examples from Phobos and your containers that we could pin this
on?


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150905/49510fcd/attachment.sig>