[erlang-questions] Maps

[Juan Jose Comellas]

I think that maps give us the chance to greatly simplify inter-module
communication. As Loïc said, I'd also like to have both maps and frames,
but right now if you want to send simple structured data to a
process/function in another module you can:

a) Use a record, with the added problem of sharing its definition and
making sure that both modules are kept in sync with it

b) Use a proplist and deal with very verbose code when manipulating it

This is becoming increasingly relevant with all the JSON messaging being
used in HTTP APIs and maps seem to be a great way to ease the pain in these
situations (even erlson <https://github.com/alavrik/erlson> was already
very convenient when dealing with JSON).

I don't see the need to allow anything more than atoms, binaries and
strings for the keys, though, but I do feel that forcing the keys to be
literals would severely restrict their usability for the cases I mentioned.

Juanjo


On Fri, May 10, 2013 at 12:17 PM, José Valim <
jose.valim@REDACTED> wrote:

> > Maps have the potential to replace proplists, dicts, and also some
> record misuses, where an interface requires you to include a file to have
> the records definition (the file example found in the EEP is one). They're
> much more interesting to implement.
>
> I am not sure realistically speaking how much Maps will replace proplists.
> They are extensively used in OTP and maps don't really seem to provide a
> huge advantage over them. My fear is adding more inconsistency to the
> libraries since some will accept maps as options, others accept proplists.
> The benefits would have to be considerable to replace proplists and I don't
> think it is the case now.
>
> But I agree; they can replace a good amount of dict usage (hard to say if
> it will be a full replacement without proper benchmarks) and record misuses.
>
> > Personally not having maps prevents me from doing a particular project,
> unless I want to spend all my time manipulating dicts of dicts or records
> of records. Hence my only question about the maps proposal about recursive
> updating being built-in.
>
> Agreed, nested access/updates are definitely a pain. Although there are
> other ways to ease this, like:
>
>     access:find_in(NestedStructure, [dict_key, #some_record.a,
> another_key])
>     access:store_in(NestedStructure, [dict_key, #some_record.a,
> another_key], Value)
>
> So even if we don't get a recursive update built-in, it seems we can
> provide good solutions to the problem.
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Lead Developer
>
>
> On Fri, May 10, 2013 at 8:34 AM, Loïc Hoguin <essen@REDACTED> wrote:
>
>> On 05/10/2013 03:41 PM, Natesh Manikoth wrote:
>>
>>> Erlang newbie here. This comment therefore is not about the merits of
>>> the proposals.
>>> I detect a certain tendency to dismiss suggestions if the suggestions
>>> are not germane to that particular user's current (or past) needs.
>>>
>>
>> Not dismissing it here, I'd be happy to have both, but maps are solving a
>> problem (dict manipulation is incredibly tedious and time consuming in
>> Erlang) while frames simply improve what we already have.
>>
>> Personally not having maps prevents me from doing a particular project,
>> unless I want to spend all my time manipulating dicts of dicts or records
>> of records. Hence my only question about the maps proposal about recursive
>> updating being built-in.
>>
>> Not having frames just requires me to know about a few pitfalls, but
>> doesn't prevent me to get the job done.
>>
>>
>> --
>> Loïc Hoguin
>> Erlang Cowboy
>> Nine Nines
>> http://ninenines.eu
>> ______________________________**_________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130510/6787338b/attachment.htm>