[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28753: 25.3; Functions to get alist from hash table and vice versa

From: Philipp Stephani
Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa
Date: Sat, 30 Dec 2017 20:40:25 +0000

Michael Heerdegen <address@hidden> schrieb am Di., 7. Nov. 2017 um 14:29 Uhr:
Noam Postavsky <address@hidden> writes:

> Drew Adams <address@hidden> writes:
> > Any news on this?  There is no general, abstract
> > solution proposed, so far, to meet the needs met
> > by the specific alist <-> hash-table code I sent.
> Did you have any comments for my proposal in #29?

That's clever.

OTOH I'm not convinced that `map-into' is a good abstraction.  Every
goal type might have an individual set of useful parameters, especially
when we want to add support for other map types in the future.  Our
choice now to unite those in one conversion interface function might
result in quite a mess later.

I don't think a unified conversion interface is that important. The various structures used for mappings are just too different. For example, alists and plists aren't real types, they are only defined by their usage. Hash tables, on the other hand, are real types, with a per-object comparison function, a non-nil empty value, etc. These two kinds of objects are just too different to treat uniformly. Also, in most cases it is statically known which kinds of objects are involved, so a generic function that dynamically selects on the type of object isn't that useful. How about adding some simple conversion functions to subr.el such as
(defun alist-to-hashtable (alist &rest keys) ...) 
(defun hashtable-to-alist (hashtable) ...)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]