<div dir="ltr">I don't think maps are meant to replace *all* use case of records. Maps are meant to replace *bad* use case of records. Before maps if you simply wanted to load data from a database you didn't really have a suitable option. Tuples are unsuitable for anything with more than a couple fields, records are too rigid/verbose, dicts don't allow pattern matching and so on.<div>
<br></div><div>Many of those use cases ended-up using records and that generated friction. With maps we have a better structure to address those cases and hopefully people will complain less about records... exactly because their rigidness will now be treated as a feature rather than a dread.</div>
<div><br></div><div>An example is the file:read_file_info/1 function. It would be much better returning a map than a record that you have to import. Note that I am not saying this change should happen, it is just an example.</div>
<div><br></div><div>I think Robert once said "if you want to share records, sit down until the feeling passes". Maybe now it can be changed to "sit down and write it as a map".</div><div><br></div><div>
$0.02 poorer,</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div><br></div><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>
</div>
<br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 9:53 PM, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+10000<br>
<br>
I find the idea of maps replacing records very confusing. The compile<br>
time static nature of records is very useful, even if it doesn't pertain<br>
to every situation you want a random access key/value data structure.<br>
<br>
A record as Fred mentions makes you think about the type and the API<br>
from the module more.<br>
<br>
And will you be able to define types on keys with maps for static<br>
analysis like with records?<br>
<br>
Tristna<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Feb 1, 2014, at 12:14 PM, Fred Hebert wrote:<br>
> I agree here. I do not see maps replacing records. I do not want to see<br>
> them replacing records either.<br>
><br>
> Maps should be a replacement of data structures like dicts and gb_trees,<br>
> in my opinion, but I still prefer records within a module module, where<br>
> I feel their restrictiveness is welcome, for two main reasons:<br>
><br>
> 1. crash early in live code upgrades, despite, I'm sure, a<br>
> lot of people disagreeing with me.<br>
><br>
> A badly planned upgrade should die rather than leading to corrupted<br>
> state. If you're crashing in your record conversion, be thankful<br>
> you're not running with bad state introducing subtle bugs (and<br>
> shameful of not having planned your upgrade better, in a way!)<br>
><br>
> 2. The module isolation inherent to records makes people think at a<br>
> protocol level and with their API much, much better than the common<br>
> pattern of saying "screw it", sharing the state around, and breaking<br>
> abstraction all over. I like how it constrains the programmer to think<br>
> of what should be passed around in messages, and that maps may remove<br>
> that "think hard" part of the problem.<br>
><br>
> APIs are hard, and the restrictions record bring forth are welcome to<br>
> me.<br>
><br>
> Maps should be especially nice and enable more complex dictionary<br>
> manipulations, nested key/val mapping, and so on, and in terseness of<br>
> operations. More elegantly, they could be a decent fix to 'use ETS to<br>
> optimize K/V operations', although they won't benefit from the same<br>
> parallel access.<br>
><br>
> I plan to explain this and possibly revisit some code snippets from the<br>
> Learn You Some Erlang site in an add-on chapter, and also show what I<br>
> wouldn't change.<br>
><br>
> Regards,<br>
> Fred.<br>
><br>
> On 02/01, Mark Nijhof wrote:<br>
> > Hi Joe (and the rest of the list),<br>
> ><br>
> > Ok right up front, I'm not a Guru, I have only been working with Erlang for<br>
> > about 7 happy months :-)<br>
> ><br>
> > I have a question about the "Records are dead - long live maps" statement<br>
> > you make in your post. One of the nice things I like about records is is<br>
> > that they are a "typed" collection of key->value pairs. When I pass a<br>
> > record around I can look up the definition and know what I can and cannot<br>
> > do with it, and also see what a function expects. Also pattern matching<br>
> > purely on the record type is a great initial filter. When I look at maps<br>
> > they look more like a proplist replacement, something that is just as<br>
> > flexible (more so I guess) but with better usage?<br>
> ><br>
> > So the question really is, how do you see maps replacing records? Would we<br>
> > add a map_type property to the map to distinguish between different maps?<br>
> > Or purely on it's data structure it self?<br>
> ><br>
> > If this is a silly question then I am happy to read about it in one of your<br>
> > awesome rants.<br>
> ><br>
> > -Mark<br>
><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>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Tristan Sloughter<br>
<a href="mailto:tristan.sloughter@gmail.com">tristan.sloughter@gmail.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>