Hi Cedric, Thanks....very insightful! On Sunday, January 5, 2014 1:30:07 AM UTC+3, Cedric Greevey wrote: > > 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.
