GNU bug report logs - #47425
26.3; `plist-get', `plist-put' should accept a TEST function

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>, Philipp Stephani <p.stephani2 <at> gmail.com>, Nicolas Petton <nicolas <at> petton.fr>, "47425 <at> debbugs.gnu.org" <47425 <at> debbugs.gnu.org>
Subject: bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST function
Date: Mon, 27 Jun 2022 14:39:30 +0000

> Then again, plists should never have existed, in my book.
> They're just strictly worse than alists as datastructures.
> Their only advantage is that sometimes when you write them by hand it
> they're somewhat more compact (fewer dots and parentheses) but for
> those cases `eq` is always good enough in my experience.
>
> I'd be curious to hear of a use case where plists are better than
> alists while at the same time requiring a non-eq comparison.

Wow.  Stefan and I actually agree on something. ;-)

(Well, I wouldn't go as far as saying that they
never should have existed.  But as far as listie
things go, they're definitely nowhere near as
useful as alists.)

But whether plists should benefit from TEST
functions other than `eq' is unrelated to whether
alists might be generally - or even always "better"
than alists.

The fact is that some users use plists, even when
they could, and maybe even should, use alists.  And
this is likely to continue, if not increase, due to
experience with other languages and other key-value
representations (JSON etc.).

(Yes, IMO the manuals could tout the advantages of
alists more, or compare & contrast plists and alists
more.  But that's not a reason not to give plist
functions an optional TEST arg.)

Plists with, e.g., string keys aren't uncommon, and
that's likely to continue.  That's kinda the point,
here.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.