You might wish to consider a different data structure. For example, the inner objects might be better off as maps with named keys, so your lookup keys would be things like :amount rather than 5. And instead of out of band values like the string "N/A" you'd just omit a mapping in such cases. At the very least you may wish to consider using nil instead of "N/A" as an out of band value for "not there".
But a map would allow easily adding more data later on, as well as enable giving the lookup keys meaningful names, and would keep the existing keys stable when new ones were added. A map may also perform better if you end up with a lot of optional keys, as missing mappings don't take up space while "N/A" values in a vector do. As for naming integer positions using constants, such as (def amount 5), there are two weaknesses with that approach. First, inserting new values will shift all of the existing ones that are farther to the right to higher indices, so you'd have to change "amount" to 6 and hope you hadn't missed any direct lookups with 5 instead of amount. But if you use a map with a key of :amount, adding more keys can never move the actual amount value away from :amount. And second, you can namespace keys to avoid collisions, with :my-ns/amount and :other-ns/amount not colliding. You can namespace def'd integer constants too, with (in-ns 'my-ns) (def amount 5) and (in-ns 'other-ns) (def amount 7), but if one day you end up with a situation where two namespaces def two different things to the key 5, the namespacing isn't going to help you. Maps with named and namespaceable :keyword keys are much more robust and scalable in large (or potentially-in-the-future-large) projects and in the presence of many optional keys. With Clojure, it's strongly recommended to use maps with named keys instead of positionally-significant entries in vectors to represent structured tuples of data like you seem to have here. The robustness becomes especially significant if you save and load data and keep old data around as the application grows. If you reorder the vectors, or insert new fields before existing ones, and then read in old data, the values will end up with the wrong keys, whereas if you use maps, keywords, and edn format the values in old data can never end up reading back in with the wrong keys (as long as you never rename already-used keys for any reason, which with meaningful names and especially namespacing you should never need to do). -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
