[erlang-questions] towards a unified dict api

[Robert Virding]

----- Original Message -----
> 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.

Yes, the most important thing is definitely that the various dict modules all have the same API. My thought with having separate modules for each implementation would be that it would be easier to add new and different implementations. You could have versions tuned to different types of usage profiles. Even if you add the ordered tree option to 'dict' I think there should still be a version of it in a separate module, like gbdict. For backwards compatibility.

Robert