7

Let's say I need to associate symbols with directories, and this will only need to be done for a small number of boundp symbols.

The way I see it, there are two easy ways to do that:

  1. Store this association in a separate variable (alist or a hash map). This way the directory of each symbol would be accessible with (cdr (assq SYMBOL my-alist)).
  2. Store this in a symbol property. This way, it would be accessible with (get SYMBOL 'my-directory).

Which of these would be the idiomatic way of keeping track of this information?

Malabarba
  • 22,878
  • 6
  • 78
  • 163
  • It would be worth indicating whether you know with certainty that there's no use-case for anyone wishing to dynamically bind the values in a temporary scope (as that would pretty much rule out option 2). – phils Jan 30 '15 at 02:03
  • @phils good point. By design it's not meant to be let bound, but I think it's a valid concern. You never know what use cases other people might find for your functions. – Malabarba Jan 30 '15 at 02:07
  • @phils: Just what do you mean? Only the symbol props, not the symbol values, are in question here, no? `(defvar s 5) (put 's 'd "c:/abc/") (let ((s 4)) (message "d: %s, val: %S" (get 's 'd) s))`. And OP: why do you speak of "functions", not symbols? I must be missing something. – Drew Jan 30 '15 at 04:02
  • @Drew he meant let binding the directory associated with a symbol. It's not possible if you use symbol properties, but it's possible if you store this information in a variable such as an alist (you just let bind the alist). As for your second question, I said "functions" because all of this behaviour will be wrapped by functions of course. I don't think I've ever seen a package without functions. :-) – Malabarba Jan 30 '15 at 08:05
  • If you two understand each other then no need to explain, but FWIW I still do not understand. By "binding a dir" I assume you mean binding a variable to a dir string. It's certainly possible for the value of a symbol property to be a symbol, whose symbol-value holds the dir string. `let`-binding that dir-string symbol (which is used as the prop value) should not be a problem. (Feel free to ignore if not pertinent.) – Drew Jan 30 '15 at 14:48
  • Drew: That's certainly true. My comment was based on the symbol property value being (directly) a directory path string. – phils Jan 30 '15 at 15:40

2 Answers2

7

It really depends on the use cases.

Generally speaking, symbol properties are "low-level" / "internal" features and one should not use them for "user-level" stuff. However, there is a place for everything :-)

A few points you might want to consider are:

  1. Speed: symbol properties are the fastest, closely followed by hash tables; alists are slow.
  2. It is easier to reset your system (i.e., remove all the vestiges of your package) with alist/hash table (reset the variable to nil) than with symbol properties (iterate over the obarray and eliminate all the relevant properties from the all symbols).
  3. It is easy to dynamically shadow the setting using alist; much harder with hash tables and symbol properties.

Another option you might want to consider is .dir-locals.el.

sds
  • 5,928
  • 20
  • 39
  • Good answer. Dunno about #2, however. What do you mean by "reset your system"? Are you talking about the relative difficulty of removing a property from a symbol (vs, e.g., a key from an alist)? – Drew Jan 30 '15 at 04:06
  • @Drew: I clarified my point. It is better now? – sds Jan 30 '15 at 04:10
  • Yes, completely clear now. I wondered if you didn't perhaps mean that. – Drew Jan 30 '15 at 04:22
0

As long as you use the canonical name for the directory, either a hashtable or an alist is functional. If you expect the user to modify or inspect the data, use an alist. Otherwise, a hashtable works best and will scale much better.

Ted Zlatanov
  • 404
  • 2
  • 4