Great, so these approaches are suggesting we wrap every value in a vector
or a hash map (as the lisp cast article does). That doesn't really help
much at all. Why is:
[[:image/name "img.png"]
[:encode/width 42]
[:encode/height 33]]
Any better than
{:image/name "img.png"
:encode/width 42
:encode/height 33}
Or perhaps people aren't suggesting vectors of vectors, I don't know. All
of it makes no sense to me when I look at in-production Clojure code. I
don't pass image names around as bare strings. I pass them around as part
of a hashmap where the keys give context to the strings, and also allow me
to pass in other data about the parameter.
Variants and sum types seem to come from OCaml and the like where strict
typing makes them much more needed. But in Clojure we prefer heterogeneous
collections, so I just don't understand why I would ever want variants.
They complicate the code for really no benefit. The complexity they are
attempting to solve can be solved by simply using maps and records instead
of bare values.
On Tue, Aug 22, 2017 at 5:43 PM, James Reeves <ja...@booleanknot.com> wrote:
> On 22 August 2017 at 23:04, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
>> 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 don't think that example is a representative use of variants in Clojure.
> More typically, variants are used like key/value pairings that exist
> outside a map. For example:
>
> [:person/name "Tim"]
>
> If you actually have a map, the key/value pairs speak for themselves:
>
> #:person{:name "Tim", :grade "B"}
>
> We can tell this is a "person" because it adheres to a particular shape,
> which can be specced out:
>
> (s/def :person/student (s/keys :req [:person/name :person/grade]))
>
> But if you just have a key/value pairing, the value alone doesn't tell you
> much:
>
> "Tim"
>
> Using a vector to represent a key/value seems to fit in well with how
> Clojure currently works:
>
> (find m :person/name)
> => [:person/name "Tim"]
>
> But there's no "s/variant" or "s/entry" spec that's as convenient to use
> as s/keys.
>
> --
> 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.
