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?

Improve this question
6
  • 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, 2015 at 2: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, 2015 at 2: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, 2015 at 4: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, 2015 at 8: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, 2015 at 14:48

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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, 2015 at 4:06
  • @Drew: I clarified my point. It is better now?
    – sds
    Jan 30, 2015 at 4:10
  • Yes, completely clear now. I wondered if you didn't perhaps mean that.
    – Drew
    Jan 30, 2015 at 4: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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.