>> I'm not sure why you think that it "complicates the code, and makes it
harder to understand".
Alright, I'll use the phrase: using vectors as variants complects order
with data. If you hand me a vector that says [:name "tim"] I have to know
that "the first thing in this vector is the name of the thing, the second
thing is the value of the thing". In addition, I have to know that you
passed me a variant. But if you simply passed me either #my.app.Name["tim"]
or #my.app.Variant{:key :name :value "tim"} I can programmatically
deconstruct that value into something usable by my system.
As much as possible I try to build my apps in such a way that the program
can self-explore the data you give it to self-optimize, self-extend, or
otherwise provide flexibility to the programmer. You can't do that with a
variant as a vector. Hand a vector to a function and the logic has to be
something like "If this is a two element vector and the first thing is a
keyword, then this might be a variant, but I'm not sure because it could
also just be a vector". While if you pass in a record, type, or even a
variant type, it's trivial to have a program recognize that value and act
upon it.
As far as performance goes, this is normally the sort of thing that gets
baked into an app at a pretty low level, that's why I suggest it should be
as fast as possible. If you're going to be processing millions of these
things during the life of an app, and transforming them from one format to
another, a little tweaking here and there may save you some pain in the
end.
Timothy
On Sun, Sep 6, 2015 at 8:14 AM, James Reeves <ja...@booleanknot.com> wrote:
> On 6 September 2015 at 14:41, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
>> >> "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.
>>
>
> I don't see why it "abuses a collection type". Vectors in Clojure are not
> inherently homogenous, any more than maps are. If it's valid to use a bare
> map to hold data, then it's equally valid to use a bare vector.
>
> If you're going to argue that variants need to be wrapped in a type, then
> surely that must apply to maps as well. Yet bare maps are used all the time
> in Clojure. We don't need to enforce the shape of data with deftype and
> defrecord; if necessary, we can do that with preconditions, runtime schema,
> or static types.
>
> 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 have the same problem with records; arbitrary keys can be added to the
> structure.
>
>
>> You also can't extend protocols to them without also applying those
>> protocols to vectors of all sizes.
>>
>
> But if you don't need protocols, then there's no problem.
>
>
>> 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.
>>
>
> If that's your performance bottleneck, then optimise it with a deftype by
> all means, but I imagine that in most cases that's not going to make a
> significant difference.
>
>
>> 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?
>>
>
> Variants are just one use of vectors. Vectors are not homogenous
> collections. It's perfectly valid to store a particular data value at a
> particular index. For example, a coordinate [x y] is a perfectly valid use
> for a vector in my book.
>
> I'm not sure why you think that it "complicates the code, and makes it
> harder to understand". All the examples I've seen of variants have been
> exactly the opposite.
>
> - 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.
