But Datomic has E in [e a v] which links multiple [a v] pairs into an
entity...which is basically a map. So I don't think that applies here.
GET /example HTTP/1.1
Host: www.example.com
[:request/method :get]
[:request/uri "/example"]
[:request/protocol "HTTP/1.1"]
[:request/header ["host" "www.example.com"]]
Once again, a ad-hoc encoding. What is "GET", what is "/example". I see
that datastructure and all I see are hashmaps.
Do it the way ring does ;-)
{:method :get
:uri "..."
:headers [...]}
On Tue, Aug 22, 2017 at 9:14 PM, James Reeves <ja...@booleanknot.com> wrote:
> On 23 August 2017 at 03:48, 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.or
>> g/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.
>>
>
> Sometimes it's an advantage to have a deliberately constrained format,
> particularly when it comes to storage or indexing. Datomic, for instance,
> is effectively an indexed event log of [e a v t] tuples.
>
> If you're in a situation where the event data can and may expand, then use
> a map. But I'd argue that there are situations where the scope is limited,
> or you want a deliberate and hard constraint on what data is in an event.
>
> Another possible situation is if you're parsing map data incrementally.
> For example, a Ring request map could be read in as a series of key/value
> pairs:
>
> GET /example HTTP/1.1
> Host: www.example.com
>
> [:request/method :get]
> [:request/uri "/example"]
> [:request/protocol "HTTP/1.1"]
> [:request/header ["host" "www.example.com"]]
>
> I'm not saying that variants should be favoured over maps in all
> situations; just that there are situations where you're certain that you
> need key/value pairings.
>
> --
> 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.
