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
> <javascript:>> 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.
