bearophile wrote:
Benji Smith:
Especially since an associative array should have a .keys property that
returns a set.
I don't agree. I think associative arrays should have .keys/.values/.items that return a
lazy view that acts like a .set/.list/.list of pairs. Such "lazy views" don't
actually store anything, they are very light. This design is now present in Python3, Java
and I have done very similar things in my dlibs (named xkeys/xvalues/xitems in my dlibs,
but xkeys isn't a set-like thing yet).
Actually I think we do agree. From an API perspective (rather than an
implementation perspective), I think the .keys property should generally
return a lazily constructed result (object? struct? I don't really
care). But I think it should conform to some standardized notion of
"set-ness" (interface? concept? again, I don't care).
HashSets are a perfectly acceptable implementation for me, as are Set
interfaces, but I know some people won't like them, and those impl
details aren't a big deal to me.
But whatever notion the language uses for its "Set" construct should be
the same dohickey used by the AA .keys property.
(Incidentally, I also think the natural set operations, like
intersection and mutual exclusion, are just as handy for maps as for sets.)
It's less semantically clean to define certain set operations on AAs, because
for example you have to decide what to do when keys are equal but their values
are not. You can avoid such semantic troubles altogether performing set
operations just only on the lazy view of the keys.
You just have to define those operations on pairs rather than just on
single values (for example, the union of two maps is naturally a multimap).
--benji