>> "Variants fulfil the same purpose as key/value pairs in a map. The key
denotes a context-sensitive purpose for the data, rather than its type."
Then use a key/value type. That's my problem with this approach, it abuses
a collection type and therefore creates confusion as to the type of data is
contains. At least create something like this:
(deftype Variant [name value])
Or if you don't want to be bothered, use clojure.lang.MapEntry.
That way I won't accidentally use the variant with conj, concat, count,
pop, push, or the dozens of other vector functions that don't apply to
variants at all. You also can't extend protocols to them without also
applying those protocols to vectors of all sizes.
In addition a variant deftype (or record) will only need 1 allocation each
time you create it. Doing [:foo :bar] requires two allocations: one for the
vector, and one for the tail array. In addition it imposes another pointer
deref on every access as you have to jump from the type to the tail array
to the value.
All in all, I see very little reason to use vectors as variants instead of
a custom type, it complicates the code, and makes it harder to understand.
Vectors aren't always vectors...they could also be variants?
Timothy
On Sun, Sep 6, 2015 at 2:57 AM, Amith George <strider...@gmail.com> wrote:
> TIL that "tagged literals" have an existing meaning in clojure. In my
> mind, the terms "tagged vector" and "tagged literal" were interchangeable.
> From a quick Google search there doesn't seem to be an existing meaning for
> "tagged vector". I think we can agree that it a representation of variants
> in Clojure.
>
> So given that, if we want to represent a single key/value pair, the
>> most natural way to do it would be:
>>
>> [:foreground #color/rgb "ff0000"]
>>
>> Variants fulfil the same purpose as key/value pairs in a map. The key
>> denotes a context-sensitive purpose for the data, rather than its type.
>>
>
>
> Could you elaborate on what you mean by variants being like a key value
> pair? Also, for the purposes of discussing variants, we can ignore reader
> tags right? I understand they serve a different purpose. The example in her
> talk had the map
>
> {:type :pickup :store-id 123
> :address nil
> :email nil}
>
> and the equivalent variant was `[:pickup 123]`
>
> If the map was instead
>
> {:pickup {:store-id 123}
> :digital nil
> :delivery nil}
>
> then yes, a variant could be thought of as a key value pair. Is this what
> you meant?
>
>
> On Sunday, 6 September 2015 13:29:05 UTC+5:30, James Reeves wrote:
>
>> On 6 September 2015 at 02:31, Timothy Baldridge <tbald...@gmail.com>
>> wrote:
>>
>>> >> Thanks, it helps to know using a tagged vector is a real pattern :)
>>>
>>> I don't know that it's a "real pattern". If I saw code like this in
>>> production I would probably raise quite a stink about it during code
>>> reviews. It's a cute hack, but it is also an abuse of a data structure. Now
>>> when I see [:foo 42] I don't know if I have a vector of data or a tagged
>>> value. It's a better idea IMO to use something like deftype or defrecord to
>>> communicate the type of something. I'd much rather see #foo.bar.Age{:val
>>> 42} than [:foo.bar/age 42]. At least then when I do (type val) I don't get
>>> clojure.lang.PersistentVector.
>>>
>>
>> I'll have to disagree with you here. To my mind, tagged literals don't
>> quite have the same purpose as variants do.
>>
>> For example, consider a map:
>>
>> {:foreground #color/rgb "ff0000"
>> :background #color/rgb "ffffff"}
>>
>> The hex strings are given a tag to indicate the type of data they
>> contain, while the keys in the map tell us the purpose of that data.
>>
>> We clearly wouldn't write something like:
>>
>> #{#foreground {:val #color/rgb "ff0000"}
>> #background {:val #color/rgb "ffffff"}}
>>
>> So given that, if we want to represent a single key/value pair, the most
>> natural way to do it would be:
>>
>> [:foreground #color/rgb "ff0000"]
>>
>> Variants fulfil the same purpose as key/value pairs in a map. The key
>> denotes a context-sensitive purpose for the data, rather than its type.
>>
>> - James
>>
> --
> 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.
