bug#47425: 26.3; `plist-get', `plist-put' and proposed TEST function

[Drew Adams <drew.adams@oracle.com>]

> CL-style keyword arguments to modify list operations are clunky.
> Unless we implement them in an extra-complicated way, they will slow
> down the usual case, too.  I understand the motivation for proposing
> this change, but let's solve it in a cleaner way that doesn't invite
> copying the bad designs of CL.

I don't think this bug thread has anything to
do with keyword arguments or even with keywords
(e.g. :foobar) in any other way.  Keywords are
anyway symbols, so they compare fine with `eq'.

The suggestion was to add a TEST optional arg,
not a keyword :test arg.  IOW, follow what we
usually do in Emacs Lisp.

The motivation here is to support plists with
keys, such as strings, that can't be usefully
compared with `eq'.

> Here are two ways that occur to me.
> 
> * The applications that want to compare property names with `equal'
> could canonicalize those names.  For instance, intern the strings
> you want to use as property names, perhaps in a special obarray.
> Then you can use `plist-get' and `plist-put' on them and get the
> results you want.

Someone writing code from scratch can always
use symbols as keys (plist properties).  That's
not the problem.

The idea is to support existing plists that
have string keys.  (And some users will end up
with such plists, one way or another.)

> * Define functions `plist-get-equal' and `plist-put-equal'.
> Instead of complicating the definitions of widely used functions
> `plist-get' and `plist-put', it will define two new functions
> that most users won't need to pay attention to.

That solution is OK also.  That won't help
someone who comes across plist-get and -put
and mistakenly tries to use them with string
keys, but that's OK.  (After all, we have memq
and member...)