[erlang-questions] analogue of lists:keyfind and other lists:key*** functions for lists which contain maps

[Denis Justinek]

In case someone finds it useful; Sergej's implementations of
mapstore/mapfind are available on github (bkdcore / butil module):

https://github.com/biokoda/bkdcore/blob/master/src/butil.erl

2014-11-23 16:26 GMT+01:00 Loïc Hoguin <essen@REDACTED>:

> I would +1 that. A tuple list and a map list are two different things, and
> it would be very unusual to see one with both.
>
> Also would like to add that as they are operating on different types there
> should be separate functions (mapfind and mapstore are indeed good names).
>
> On 11/23/2014 05:04 PM, Sergej Jurecko wrote:
>
>> I just converted a ~5k lines of code project into using maps. I wrote
>> myself mapfind(Key,Value,L) and mapstore(Key,Val,L,Map). That was all I
>> needed. I did not care about compatibility with other types in list.
>>
>> Is worrying about mixing tuples/records with maps in a list really
>> necessary? In the 6+ years of writing erlang, I don’t think I’ve had a
>> list of mixed types more than a couple of times.
>>
>>
>> Sergej
>>
>> On 23 Nov 2014, at 15:43, Lukas Larsson <lukas@REDACTED
>> <mailto:lukas@REDACTED>> wrote:
>>
>>  Hello,
>>>
>>> I agree with you that in certain situations they would be very
>>> convenient. I've myself already written these functions in a couple of
>>> modules.
>>>
>>> How do you imagine the semantics would work? It is fairly straight
>>> forward when the list only contains maps or tuples.
>>>
>>> lists:keyfind(you, name, [#{ name => me, from => here }, #{ name =>
>>> you, from => there}]) returns #{ name => you, from => there}.
>>>
>>> But if we start to mix them some interesting corner cases pop up:
>>>
>>> lists:keyfind(2, 1,[#{ 2 => 3 },{2, 4},#{ 1 => 2 } ]) returns {2,4} or
>>> #{ 1 => 2 }?
>>> lists:keyfind(1, id, [{1,2}, #{ id => 2}, #{ id => 1}) returns #{ id
>>> => 1 } or crashes as id is not a valid key for {1,2}?
>>>
>>> Or error cases of today:
>>>
>>> lists:keyfind(2, id, []) today gives badarg, but should return false
>>> for a map list?
>>>
>>> The safest way to introduce these functions would be to create new
>>> ones called something like lists:mkeyfind, but if possible it would be
>>> very neat to use the same API. It really is unfortunate that
>>> lists:keyfind is so forgiving today, you can mix and match whatever
>>> you want in the list and keyfind will quietly ignore it.
>>>
>>> Also we have to consider which of the lists:key* functions we want a
>>> map counterpart? Does it make sense for all of them?
>>>
>>> Thoughts? Ideas? Suggestions?
>>>
>>> Lukas
>>>
>>>
>>> On Sat, Nov 22, 2014 at 7:33 PM, John Doe <donpedrothird@REDACTED
>>> <mailto:donpedrothird@REDACTED>> wrote:
>>>
>>>     It would be nice to extend lists module with a set of optimized
>>>     functions like lists:key*** for lists containing maps.
>>>
>>>     _______________________________________________
>>>     erlang-questions mailing list
>>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>>     http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> --
> Loïc Hoguin
> http://ninenines.eu
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 

Denis Justinek - @: denis.justinek@REDACTED - www:
http://about.me/djustinek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141123/fee791ab/attachment.htm>