[erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released.

[José Valim]

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.

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.

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.

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".

$0.02 poorer,




*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Lead Developer


On Sat, Feb 1, 2014 at 9:53 PM, Tristan Sloughter <
tristan.sloughter@REDACTED> wrote:

> +10000
>
> I find the idea of maps replacing records very confusing. The compile
> time static nature of records is very useful, even if it doesn't pertain
> to every situation you want a random access key/value data structure.
>
> A record as Fred mentions makes you think about the type and the API
> from the module more.
>
> And will you be able to define types on keys with maps for static
> analysis like with records?
>
> Tristna
>
> On Sat, Feb 1, 2014, at 12:14 PM, Fred Hebert wrote:
> > I agree here. I do not see maps replacing records. I do not want to see
> > them replacing records either.
> >
> > Maps should be a replacement of data structures like dicts and gb_trees,
> > in my opinion, but I still prefer records within a module module, where
> > I feel their restrictiveness is welcome, for two main reasons:
> >
> > 1. crash early in live code upgrades, despite, I'm sure, a
> >    lot of people disagreeing with me.
> >
> >    A badly planned upgrade should die rather than leading to corrupted
> >    state. If you're crashing in your record conversion, be thankful
> >    you're not running with bad state introducing subtle bugs (and
> >    shameful of not having planned your upgrade better, in a way!)
> >
> > 2. The module isolation inherent to records makes people think at a
> >    protocol level and with their API much, much better than the common
> >    pattern of saying "screw it", sharing the state around, and breaking
> >    abstraction all over. I like how it constrains the programmer to think
> >    of what should be passed around in messages, and that maps may remove
> >    that "think hard" part of the problem.
> >
> >    APIs are hard, and the restrictions record bring forth are welcome to
> >    me.
> >
> > Maps should be especially nice and enable more complex dictionary
> > manipulations, nested key/val mapping, and so on, and in terseness of
> > operations. More elegantly, they could be a decent fix to 'use ETS to
> > optimize K/V operations', although they won't benefit from the same
> > parallel access.
> >
> > I plan to explain this and possibly revisit some code snippets from the
> > Learn You Some Erlang site in an add-on chapter, and also show what I
> > wouldn't change.
> >
> > Regards,
> > Fred.
> >
> > On 02/01, Mark Nijhof wrote:
> > > Hi Joe (and the rest of the list),
> > >
> > > Ok right up front, I'm not a Guru, I have only been working with
> Erlang for
> > > about 7 happy months :-)
> > >
> > > I have a question about the "Records are dead - long live maps"
> statement
> > > you make in your post. One of the nice things I like about records is
> is
> > > that they are a "typed" collection of key->value pairs. When I pass a
> > > record around I can look up the definition and know what I can and
> cannot
> > > do with it, and also see what a function expects. Also pattern matching
> > > purely on the record type is a great initial filter. When I look at
> maps
> > > they look more like a proplist replacement, something that is just as
> > > flexible (more so I guess) but with better usage?
> > >
> > > So the question really is, how do you see maps replacing records?
> Would we
> > > add a map_type property to the map to distinguish between different
> maps?
> > > Or purely on it's data structure it self?
> > >
> > > If this is a silly question then I am happy to read about it in one of
> your
> > > awesome rants.
> > >
> > > -Mark
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> --
>   Tristan Sloughter
>   tristan.sloughter@REDACTED
> _______________________________________________
> 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/20140201/99fc649c/attachment.htm>