[erlang-questions] towards a unified dict api

[Richard Carlsson]

On 01/12/2012 06:31 PM, Robert Virding wrote:
> I think that in many cases you DO want to know about the
> implementation as different algorithms have different properties and
> choosing the right one can have a significant effect on an
> application. This was the reason we have different versions with the
> same API, so you could test and choose between them and find the best
> one. Unfortunately it took a long time before there came a new one
> after the original two.
>
> I think it is good to have at least one tree based version as well.
> Though I would much prefer to have it in a separate module (gbdict?)
> instead of baking it into the dict version. I prefer to be explicit
> rather then "hiding" behind one module. In most case you do really
> want to know what is going on. I have two tree versions that I have
> long been meaning to include in the distribution, rbdict based on
> Red-Black trees and aadict based on the same algorithms as gb_trees
> but implemented in a different way. The more the merrier.
>
> But as I said I strongly feel it is much better to have separate
> modules. It also makes it easier to add versions, which as you can
> probably understand I think there should be.

It is of course possible to *also* give gb_trees a new interface (which 
requires a new module name) although I didn't want to do that as part of 
this exercise. Still, I think that it's a good thing to just make the 
dict module itself offer both a hashed form and an ordered (tree based) 
form, because it makes Erlang more approachable. These things are not 
mutually exclusive.

The actual implementation used for the hash and tree forms could change 
between Erlang releases depending on what is deemed to be the most 
efficient; after all, the current hash table implementation is 
explicitly said to be opaque and might be replaced with some more 
efficient variant one day.

But for the basic Erlang user, I think it ought to be enough to know 
that the dict module covers most of his needs, both for ordered and 
unordered dictionaries. If he later wants to optimize his code, he can 
then familiarize himself with the other N dict-like modules in the 
distribution and pick one that might be better for his use case. If they 
all speak the same API, swapping them should then be simple.

     /Richard