Hi Kevin
For something like an account, a more idiomatic way to model this in
Clojure might be with maps:
{:account-name "John Smith"
:account-number "125-1290"}
or
{:account/name "John Smith"
:account/number "125-1290"}
If you then want to refactor your usage/naming of map keys then you can
search for usages of the keyword (Cursive has this built-in, I'm not sure
about other editors).
Clojure also has records <https://clojure.org/reference/datatypes> which
you can use to model your system. They are similar to maps, but have some
extra features. Alex Miller has a good explanation
<https://stackoverflow.com/questions/4575170/where-should-i-use-defrecord-in-clojure>
about
the tradeoffs between records and maps, and there's more discussion here
<https://groups.google.com/forum/#!topic/clojure/NY-9V6PXlWg>, and here
<https://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/>
.
On Wed, Jul 26, 2017 at 1: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.
