I find the arguments for variants very unconvincing. As you stated with
specs and s/keys you can spec the same sort of data, and in a way that's
much more open-ended.
For example:
[:person {:name "Tim" :grade "B"}]
What is the type of this data? We would probably guess a :person. But what
if we wanted to "cast" it to a :student? Well then we'd have to change the
variant tag to :student, but then it would no longer be a person, unless we
introduced some sort of inheritance that said all students are people.
I much prefer spec:
(def ::person (s/keys :req [::name]))
(def ::student (s/keys :req [::grade ::name]))
I'm very much in the camp that longs for a super fast s/valid?
implementation so I could go and re-implement multi-methods and protocols
on top of spec. Much more flexible, and honestly it more correctly models
the real world.
On Tue, Aug 22, 2017 at 3:52 PM, Didier <didi...@gmail.com> wrote:
> I'm reading on http://www.lispcast.com/reduce-complexity-with-variants
> and have seen Jeanine's talk on her encoding scheme for sum types, but for
> some reason, I'm not convinced of the benefit over a tagged record
> encoding. I see that the positional vector or hash-map suggested in the
> lispcast article has a theoretically smaller number of states, but because
> it lacks names, it seems at a higher risk of human error. Anyone has
> thoughts on this? And now that we have specs, I feel like a multi-spec
> would address concerns of the tagged record encoding by being able to
> validate that the correct set of keys exist for the given type, while also
> having the benefit of named fields. What do others think?
>
> --
> 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.
