[erlang-questions] towards a unified dict api

[Eric Merritt]

When Torben and I did signatures (something akin to java interfaces)
last year for erlware_commons we went through the same process.

You can see the dictionary signature here

https://github.com/erlware/erlware_commons/blob/master/src/ec_dictionary.erl

which contains what we came up with along those lines.

signatures are our attempt to provide, standard interfaces that are
friendly to tools like dialyzer and xref. The best part about them is
they don't require language changes.

On Fri, Dec 23, 2011 at 7:43 PM, Andrew Berman <rexxe98@REDACTED> wrote:
> I like this idea. Coming from Java, I'm used to interfaces and abstract
> classes whereby Set, Map, List, etc. implementations can share the same
> basic API except if you need to use something specific to that
> implementation.  So, basically you want to mimicking the behavior of the Map
> interface which has multiple implementations below it of HashMap, TreeMap,
> etc.  I think it greatly simplifies usage and makes switching between
> implementations far easier.  The same can/should be done with sets too, no?
>
> On Fri, Dec 23, 2011 at 2:09 PM, Richard Carlsson
> <carlsson.richard@REDACTED> wrote:
>>
>> A thing I've been tinkering with on and off for years is making a unified
>> API for dictionaries in Erlang (dict, orddict, gb_trees, ets, dets). This
>> requires figuring out a set of function names and calling conventions that
>> are mostly familiar but which don't already have a conflicting definition in
>> one or more of the modules involved.
>>
>> In the end I went for using most of the dict module API unchanged, with
>> some new synonyms, and a number of additional useful functions. I also made
>> the dict module define a new 'dict' behaviour (even though it's just an
>> interface rather than a complete behaviour).
>>
>> One particular detail is that gb_trees (with its user-unfriendly name and
>> rather different calling conventions) can now quite simply be used through
>> the dict module as an ordered variant of dict, and you can pretend you never
>> heard of the gb_trees module unless you want to use one of its specially
>> implementation-dependent functions. An ordered dict can be created through
>> dict:new([ordered_set]). This also resolved some major problems with
>> clashing function definitions.
>>
>> The code (based on the OTP maint branch) can be found here:
>>
>> https://github.com/richcarl/otp/tree/dict-api
>>
>> The quickest way of having a look at the suggested API is to follow this
>> link and scroll down to see the behaviour callback:
>>
>> https://github.com/richcarl/otp/blob/dict-api/lib/stdlib/src/dict.erl
>>
>>
>> Reactions, suggestions, and test pilots are most welcome. I'm not ready to
>> write an EEP until I feel the API is good enough. Things still on the
>> TODO-list are: updating the docs for ets and dets, figuring out a good set
>> of iterator functions, and maybe include QLC table/1/2 functions and
>> match/select functions in the API. And then the same kind of unified API
>> should be made for sets and probably also for sequences.
>>
>> A Good Yule to y'all,
>>
>>  /Richard
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

T