Sat May 11 00:42:28 CEST 2013
I am personally a ambivalent to maps as they have been presented. They are trying to solve two problems which both need solving but I don't think *one* solution is the way to go. So maps:
- are to be a dynamic alternative to records which is a Good Thing.
- are to be a faster replacement to dicts, which is always useful.
The problems are different enough so that I think that in trying to be a solution to both will mean that they will do neither in the best way. So either pick one and solve it properly, or come with two solutions.
>From my own experience I would say save the new syntax for the record alternative, this is where I would get the most out of it. Having atoms as keys would pose me no problems. Use a new data type here.
For the dict alternative having a special syntax would give me very little so I wouldn't bother about it, using functions calls handles my usage very well. It also makes it easy to test alternate implementations to find the one with the most appropriate properties, just change the name of the module. For a built in type I would prefer speed to ordering. Actually you probably wouldn't need a built in type, just suitable BIFs to manage existing tuples/lists.
I think I agree with ROK here.
Anyway, that's my take on it,
----- Original Message -----
> From: amindfv@REDACTED
> Just like in the case of lists/strings and binaries, the reason the
> conversions happen is because the data types converted to and from
> are useful in different ways!
> I agree we should avoid cluttering the language up, but if we
> view/use Maps as replacement for Dicts and Frames as replacement for
> Records, then the situation wouldn't be any more cluttered than it
> already is.
> El May 10, 2013, a las 12:30 PM, Max Lapshin <max.lapshin@REDACTED>
> > Guys.
> > erlang is a rather simple language, which is seriously spoiled by
> > endless list_to_binary and binary_to_list conversions. Are you
> > really
> > sure that we need map_to_frame and frame_to_map ?
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> erlang-questions mailing list
More information about the erlang-questions