[erlang-questions] lists:mapfind?

[zxq9]

On 2017年08月22日 火曜日 10:38:18 Max Lapshin wrote:
> Perhaps  lists:keyfind  can work with maps also?

tl;dr:
Please, no.


Brace yourself:
This really goes against the idea that maps are K/V thingies where K is a set and V is whatever.

Lists of tuples is a VERY basic functional data structure -- to the point that, more or less, an entire language and paradigm was written based on it. A convenience function over that makes perfect sense if you need to figure out things about a list of maps.

But this doesn't strike me as the underlying problem, really. This sounds a lot like someone is facing an annoying moment where their program's semantics have gotten the better of them and now they have got a list of maps that shouldn't be naked maps. They should be having a list of tuples something like [{MetaData, Map}] so that some useful meta about the map is conveyed outside of the map.

Not EVERYTHING should be inside of a map. K/V types are really limited in what they are good for. Just about any data type can be shoehorned onto inappropriate use cases.

I realize I'm getting ranty about this right now, but that's because I have spent a huge amount of time staring at semantically retarded code written by people who can only ever imagine that there is one data type in the whole language, maps, and they proceed to write reams of code for manipulating them, inspecting them, and so on when more boring, direct, semantically unambiguous code would have been dramatically better, faster, easier to debug, and more flexible (in the good ways -- "every function can take a map! hurray!" is NOT what "flexibility" is supposed to mean...).

Hidden within the desire for such a function is a deep need for some data structure refactoring. I would feel this instinctively -- and so far that instict has never steered me wrong (though occasionally there is a borderline case where there is just no good tradeoff for some reason, at least not one that is obvious within the time allocated to study of the problem, or would imply a much deeper refactoring of the program because other stuff is all globbed together by intimate knowledge of a data structure or magical keys or something).

-Craig