Maps with named keys work much better than vectors/lists for heterogenuous data. I've recently taken up OCaml as a very well-typed language, and it's basically analogous to records vs tuples tradeoffs there.
Clojure.spec can help at a larger scale. You can do the same encapsulation as Java by writing accessors in a namespace, it sounds to me like you didn't abstract it out early enough. On Jul 25, 2017 9:52 PM, "Kevin Kleinfelter" <kleinfelter.gro...@gmail.com> wrote: I ran into the 'refactoring an unnamed type' problem. I'd like to know how experienced Clojurists avoid it. I've got an account record/structure. It has things like an account name, account number, etc. I started off storing it in a vector, because it had just two elements. Account name was (first v). Account number was (second v). And that worked up to a point. Over time, it has acquired enough pieces and rules that I really need to change its implementation. I need to refactor it. When it was only a few hundred lines long, in a couple of files, I could examine each line. Now that it's a dozen files and several thousand lines, I just don't have the attention span. In a language with named types, I could search for AccountRecord. I could thoroughly find all the places I used it and refactor it. Or I could change the name of the type to tAccountRecord, and the compiler would identify all the places where I used it (with error messages). In an OO language, I'd be accessing all of its pieces via getters and setters, and I wouldn't have to find all of the places where I used it, because the implementation would be a black box. But in a language with unnamed types, it's just a vector and I've just got first and second and nth to search for. That's going to find lots of irrelevant stuff. It's enough to make me pine for Java and a refactoring IDE. =:-o So how do developers who work with un-typed (or un-named type) languages avoid this sort of problem? Or, failing to avoid it, how do they clean up afterward? tnx -- 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/d/optout. -- 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/d/optout.
