[erlang-questions] towards a unified dict api

[Robert Virding]

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.

I have not yet looked through the suggestion for extending the API, but I will shortly.

Robert

----- Original Message -----
> On 2011-12-30 01:25, Steve Davis wrote:
> > On Dec 29, 11:35 am, Richard Carlsson<carlsson.rich...@REDACTED>
> > wrote:
> >> ...but you shouldn't have to know anything about the
> >> implementation.
>  >
>  > Once, I would have strongly agreed with you. Now, I am not so sure
>  > that this tenet is true for many cases. Specifically what guides
>  > this
>  > change of heart for me is the painful progress in RPC/CORBA/JRMI
>  > abstractions over the years. I suspect that it also applies to
>  > data/
>  > state sources.
>  >
>  > My 2c.
>  > /s
> 
> And I basically agree, which is why I'm not aiming for an object
> oriented approach. But I think that letting the dict module have an
> ordered version, just like ets tables, is a good idea. You still get
> to
> choose between O(n) time for an unordered table and O(log n) time for
> an
> ordered table when you initialize the dict, and from a usability
> perspective it means that for most cases where you want a functional
> dictionary data type, the dict module is all you need to know.
> 
> I couldn't get a good unified dict API until I decided to remove the
> gb_trees module from the equation by making it accessible via dict
> instead, because its current API is too different from the existing
> dict/orddict API and the name clashes got too difficult to resolve. I
> could of course also invent a new name for gb_trees, but that seems
> unnecessary.
> 
>     /Richard
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>