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.
Likewise:
>> 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.
>> [:data/retry-in 600]
If this is a web endpoint, I'd really like a URL with it:
{:op/status :busy
:retry/delay 600
:retry/url #url "http://...."}
In short variants almost never give me enough information, and when they
do, it's encoded in some sort of DSL that I have to parse or enrich if I
want nice machine level introspection.
On Tue, Aug 22, 2017 at 8:48 PM, Didier <didi...@gmail.com> wrote:
> I can see it be quick and concise for representing events, but that's also
> exactly the use case example for multi-spec: https://clojure.
> org/guides/spec#_multi_spec
>
> What happens if your event needs more data? Maybe draw needs 2 attributes,
> the card and the deck? Now you have implicit encoding, where what the
> attributes are for the event are defined by its position in the vector.
>
> Where as you could have just as easily had:
>
> {:event/type :draw :card :4s :deck :player1}
>
> You can make a vector of those for the order of the events.
>
> Yes, you can also use variants, and have:
>
> [:event/draw :4s :player1]
>
> My question is, what's the pros/cons? Its more concise, but barely. Its
> harder for it to represent optional values, you have to allow nil:
> [:event/draw :4s nil]. You can mistake the order: [:event/draw :player1
> :4s].
>
> I think to represent the type of a single element, I agree with you, but
> if you've got a compound type, at first glance, they'd appear less
> practical and more error prone to me. So your second example makes more
> sense.
>
>
> On Tuesday, 22 August 2017 19:07:56 UTC-7, James Reeves wrote:
>
>> On 23 August 2017 at 01:18, Timothy Baldridge <tbald...@gmail.com> wrote:
>>
>>> Great, so these approaches are suggesting we wrap every value in a
>>> vector or a hash map (as the lisp cast article does).
>>>
>>
>> What? No, that's not what I'm saying at all.
>>
>> If you have an unordered collection of key/value pairs where every key is
>> unique, then *of course* you use a map.
>>
>> But if you have only *one* key/value pair, how do you represent that? Or
>> if you want an arbitrarily ordered collection of key/value pairs? Or a
>> collection with repetition?
>>
>> For example, a series of events that represent a player's moves in a card
>> game:
>>
>> [:card/draw :9h]
>> [:card/draw :qh]
>> [:card/draw :4s]
>> [:card/discard :4s]
>> [:card/draw :7d]
>>
>> I've also found it a useful pattern for data access:
>>
>> [:data/found "Bob"]
>> [:data/not-found]
>> [:data/unauthorized]
>> [:data/retry-in 600]
>>
>> A [k v] vector isn't the only way of representing data like this, but it
>> is probably the most concise.
>>
>> --
>> 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.
