Juan Jose Comellas
Fri May 10 18:21:26 CEST 2013
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.
On Fri, May 10, 2013 at 12:17 PM, José Valim <
> > 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,
> 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*
> 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
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions