DIP67: Associative Ranges

[H. S. Teoh via Digitalmars-d]

On Sat, Nov 01, 2014 at 12:04:16AM +0000, Jakob Ovrum via Digitalmars-d wrote:
> On Tuesday, 28 October 2014 at 22:44:32 UTC, Freddy wrote:
> >http://wiki.dlang.org/DIP67
> >Abstraction over the build-in associative array(one type of range
> >for containers and another type for dynamic generators).
> >Plese criticize.
> 
> Any examples of what this actually accomplishes? Maybe an example of
> an algorithm that can do something useful with these primitives? A
> rationale for why these are the chosen primitives?
> 
> As the proposed "associative range" isn't consumable like other
> ranges, this seems more like a specific kind of *container*, not a
> *range*; indeed the text of the DIP seems to conflate the concepts,
> but they are separate by necessity.
> 
> Note that opIndex and opBinaryRight are already container primitives
> (see std.container). There's also the additional relevant primitive
> `removeKey`.  Beyond that though, associative containers could need
> some more fleshing out in the container concept.
> 
> As it is, I think this proposal suffers both from lack of substance
> and confusing terminology.

I think a better name would be "associative array concept" rather than
"associative range".

Basically, this DIP is proposing a set of primitives that can be used to
identify some given type as AA-like, so that generic code that expect
AA-like objects would be able to work with any type that implements the
expected interface. Ostensibly, one could then implement generic
algorithms that work with AA-like objects.

It's not a bad idea, really, except perhaps for the name. And the API
could use more careful thought to boil it down to the essentials, rather
than throwing in everything current AA syntax supports, just because AA
syntax supports it. If we can boil down AA's and AA-like types into a
small but expressive set of primitive operations, it could turn out to
be a very useful abstraction that generic code could use. The current AA
syntactic sugar can then be implemented in terms of the minimal
primitives, and one could easily build AA-like objects by implementing
the primitives, and automatically get all the syntactic sugar "for free"
via UFCS and so on.


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway