From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani
> * =E2=80=98foo=E2=80=99 wants plists while =E2=80=98bar=E2=80=99 wants= alists.
If "want" is the same thing as "must have", then bar sh= ould be setting
the var from the beginning, end of story. It should only not set the var
if it doesn't care.
There are many variables like this in emacs.
Eli recently re= minded me in
a closely related thread I have to bind coding-system-for-write around
process-send-string, for example.
Obviously, the pitfall is overlooking to bind them when you have
to. Presumably this is outweighed by the convenience of not passing a
trillion args to a function call and, more importantly, to every caller
of a function, like in the commit that removes the var, which is quite a
bit more complex (which is why I started with the other alternative).
= blockquote>No, it's never outweighted. If there are= too many parameters, you'd collecting them in an "options" o= bject and pass that around, or create a "JsonDecoder" object that= keeps the settings, etc.=C2=A0
Anyway, this point could be irrelevant if we remove the variable and
argument completely, auto-detecting plists.Can't decide if that could
be a worse idea, though.It might b= e because it could make the interface more surprising. There's a clear = type difference between hashtables and lists, so detecting them automatical= ly is fine. But "plist" isn't really a type; there's no f= undamental difference between plists and alists, and the only difference is= how they are used (assq vs. plist-get etc.). That's one of the (severa= l) reasons why I decided to not support plists in json.c at all, and I'= m still not convinced it's worth the additional interface complexity (f= or deserializing the story is probably different, as it doesn't make th= e existing interface more complex, and with the CL argument lists you alrea= dy have an actual use case).=C2=A0