<div dir="ltr">On Wed, Sep 16, 2015 at 7:15 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
On 16/09/2015, at 6:26 am, Drew Varner <<a href="mailto:drew.varner@redops.org" target="_blank">drew.varner@redops.org</a>> wrote:<br>
<br>
> A property in a proplist can be an atom or a tuple.<br>
<br>
</span>The problem is that the documentation for the proplists<br>
module says that the elements of a proplist can be ANYTHING.<br>
<br>
The documentation is a little confusing.  proplists:get_value/[2,3]<br>
only pays attention to pairs; other tuples might as well not be there.<br>
<br>
Does anyone know *why* the proplists module is so tolerant of<br>
junk in proplists?  Is it because<br>
<br>
get_value(Key, [{Key,Val}|_], _) -> Val;<br>
get_value(Key, [Key|_],       _) -> true;<br>
get_value(Key, [_|Ps],  Default) -> get_value(Key, Ps, Default);<br>
get_value(Key, [],      Default) -> Default.<br>
<br>
is the easiest thing to write, or is there a use case for it?<br>
<div><div><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br></div><div class="gmail_extra">The rationale of the proplists module was to make it easy for a program to handle options that could have been entered by a human, perhaps directly from the Erlang shell. (The first real use was in the option handling in the HiPE compiler.) I wanted it to be possible to use proplists as a drop-in replacement for most of the local option parsing hacks that were abundant in existing code - all slighty different. Looking at most modern code, I'd say that this was achieved - most people seem to be using proplists now. (Might be changing given that we have maps now - perhaps proplists should be updated to work on maps as well.) Not all expected uses of the module were for "options", though, so I didn't name it 'getopt' or similar, since that would have felt misleading.<br><br>Since such lists in existing code often could contain random stuff apart from obvious key/value pairs or atoms (flags), and I also didn't want to block someone from using proplists just because they wanted to add some nonstandard stuff, the proplists module had to be lenient and mainly ignore anything that it didn't understand. The get_value example was not written like that because it was easiest, but because there was no obvious definition of the "value" for a key if the entry is a 3-tuple or larger. So instead, a user who calls get_value is explicitly asking proplists to ignore anything but pairs and naked keys, and needs to understand this.<br><br></div><div class="gmail_extra">The proplists module was written for flexibility in how one writes the lists - not for speed (although I did make an effort to make the code as fast as possible given the constraints). Every now and then, I see someone benchmarking proplists functions and being surprised that lookups are slower than lists:keyfind() or similar. If you're having a problem with proplists performance you're using them wrong. If you need maximum speed, then extract what you need from the proplists and put the data in a form that offers faster access times, typically before you enter the main loop of your program. If you *know* that your lists are strict key/value pairs and will never be anything else, then you shouldn't be calling the proplists functions to begin with - just use lists:keyfind(), which is as fast as it can be.<br clear="all"></div><div class="gmail_extra"><div><div><br>        /Richard C<br></div></div>
<br></div></div>