<div dir="ltr">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:<div>
<br></div><div>a) Use a record, with the added problem of sharing its definition and making sure that both modules are kept in sync with it</div><div><br></div><div>b) Use a proplist and deal with very verbose code when manipulating it</div>
<div><br></div><div>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 <a href="https://github.com/alavrik/erlson">erlson</a> was already very convenient when dealing with JSON).</div>
<div><br></div><div>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.<div>
<br></div><div style>Juanjo</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 10, 2013 at 12:17 PM, José Valim <span dir="ltr"><<a href="mailto:jose.valim@plataformatec.com.br" target="_blank">jose.valim@plataformatec.com.br</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> <span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">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.</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
</div><div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div class="im"><div><br></div><div>> <span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">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.</span></div>
<div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><br></span></div></div><div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">Agreed, nested access/updates are definitely a pain. Although there are other ways to ease this, like:</span></div>
<div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"> access:find_in(NestedStructure, [dict_key, #some_record.a, another_key])</span></div>
<div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"> access:store_in(NestedStructure, [dict_key, #some_record.a, another_key], Value)</span></div><div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">So even if we don't get a recursive update built-in, it seems we can provide good solutions to the problem.</span></div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div>
<span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div>
<div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Lead Developer</span></div></span></div></span></div></font></span></div><div class="HOEnZb"><div class="h5">
<br><br><div class="gmail_quote">On Fri, May 10, 2013 at 8:34 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 05/10/2013 03:41 PM, Natesh Manikoth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Erlang newbie here. This comment therefore is not about the merits of<br>
the proposals.<br>
I detect a certain tendency to dismiss suggestions if the suggestions<br>
are not germane to that particular user's current (or past) needs.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
Not having frames just requires me to know about a few pitfalls, but doesn't prevent me to get the job done.<div><br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br></div><div><div>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>