Simple: because failing to put it in a map constrains future growth.
Putting things into a set restricts you to unique values. Putting values
into a vector constrains you to a specific ordering. And quite frankly one
little mistake like this can cause tons of refactoring down the road.
Better to write it once, simply, and extensible.
I can't tell you how many codebases I've worked on where they failed to
allow for "extra data" in either the arguments or the return of a function
or endpoint and we've had to do major refactoring once a single part of the
system needs a configuration flag.
But I guess I'd flip it around. Why would I ever want:
[:response val]
when I could have
{:status :response
:result val}
The latter is more readable, self-documenting, and extensible. I can't
think of a single design benefit the variant variant has over the map.
On Tue, Aug 22, 2017 at 9:43 PM, James Reeves <ja...@booleanknot.com> wrote:
> On 23 August 2017 at 03:58, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
>> Put let's take that and look at it under a engineering lens a bit:
>>
>> >> For example, a series of events that represent a player's moves in a
>> card game:
>> >>
>> >> [:card/draw :9h]
>>
>> You have an ad-hoc encoding of data here now. Expand it out a bit, and
>> make it machine readable instead of preferring ease of writing and you get:
>>
>> {:player/action :card/draw
>> :card/number :9
>> :card/suit :hearts}
>>
>> Much easier to introspect, and extensible as future data just flows
>> through without existing code breaking because you add extra data.
>>
>
> But possibly over-engineered. Suppose that the only function we want to
> produce is:
>
> (cards-in-hand events)
> => #{:9h :qh :7d}
>
> If we have a function that returns [k], [v] or {k v}, then I have a hard
> time buying the idea that the input to the function should be more complex
> than [[k v]].
>
> If the scope of the data is not so constrained, then sure, use a map.
>
> >> I've also found it a useful pattern for data access:
>> >>
>> >> [:data/found "Bob"]
>>
>> I've worked with systems that have done this, and I really dislike it.
>> Because now I have to zip the inputs of a function with the outputs if I
>> want a composable system usable in pipelines and the like.
>>
>> What's much better:
>>
>> {:op/status :success
>> :data/found "Bob"
>> :data/key "444-434-3323"
>> :server/ip ....}
>>
>> Now not only do I know what data I got, but where it came from, the key I
>> originally used, etc.
>>
>
> Which is useful only if you plan on using that additional data. If you are
> only ever interested in the key and value, and the function is internal,
> why dress it up?
>
> --
> James Reeves
> booleanknot.com
>
> --
> 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.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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.
