There are a couple of different things being discussed here. I don't
think there's any harm in allowing maps as frames, as long as people
understand that they're arbitrarily ordered (alphabetically by key,
but that's an implementation detail) and that keys specified aren't
optional - if they're not all there, the encoder will fail.
The first issue you raised was that we might want to have finer
control over how maps are encoded, so that we can ensure compatibility
with C structs. This is true, but we still want the decoded versions
of these ordered lists to be maps, because {:a 1, :b 2} is much more
convenient than [:a 1 :b 2] or [[:a 1] [:b 2]].
The second issue you're raising is backwards compatibility. It's
worth pointing out that neither of the above encodings are backwards
compatible: if you add new keys, the new codec won't be able to read
the old format and vise-versa. To do this, we need a somewhat more
complex encoding that both describes which values were specified and
the values themselves. This is dangerously close to what protocol
buffers already do, and I'm not sure if Gloss would be the correct
library to use for this purpose.
That being said, if someone has a decent use case for why they want to
dynamically generate backwards compatible byte encodings, I wouldn't
be opposed to having something like that in the library. I wrote the
library mostly to help me write Redis and AMQP clients, but I'm hoping
people will find it useful for a variety of purposes.
Zach
On Nov 23, 4:21 pm, Chris Perkins <chrisperkin...@gmail.com> wrote:
> On Nov 23, 3:24 pm, Zach Tellman <ztell...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 23, 12:12 pm, Chris Perkins <chrisperkin...@gmail.com> wrote:
> > > I have only taken a quick look, so maybe I'm misunderstanding the
> > > intent, but it's not clear to me how you would use this for sending
> > > and receiving structured data from, say, a C program.
>
> > > Taking your example from the wiki:
>
> > > (def fr (compile-frame {:a :int16, :b :float32}))
>
> > > Let's say I want to talk to a C program that speaks in structs, like
> > > this:
>
> > > struct Foo { short a; float b; }
>
> > > The problem is, the C program cares about order - the short comes
> > > before the float. How does the Clojure program know what order I need
> > > the fields in, since I have specified the format with a map; an
> > > unordered data structure? Is there another way to specify a structure
> > > where order of the fields matters? If so, why have two ways of doing
> > > it? Or am I just missing something?
>
> > Good question. The solution didn't make the cut for my initial
> > release, but will be added soon. My plan is to have an (ordered-
> > map ...) frame which encodes and decodes the keys in the given order.
> > So for C interop, the frame would be
>
> > (ordered-map :a :int16, :b :float32)
>
> > An alternative would be to just turn any vector which is alternating
> > keys and types into an ordered-map, but that seems a bit too magical.
>
> > Zach
>
> I would humbly submit that perhaps you should just go for ordered
> formats, always. For example, a vector of two-element vectors could be
> the canonical format:
>
> [[:a :int16] [:b :float32]]
>
> Then you could add some macro-sugar to make it pretty:
>
> (struct :a :int16 :b :float32) => (compile-frame [[:a :int16]
> [:b :float32]])
>
> The reason I say this is both to simplify (have only one way to
> specify a format), because I can envision people getting quite far
> down a path of relying on the byte-ordering coming out of compile-
> frame, simply due to the fact that clojure uses PersistentArrayMap for
> small maps, giving the illusion that they are ordered. Then one day
> they confidently add that Nth field to their struct definition (where
> N appears to currently be 10), and suddenly they have byte-soup coming
> out.
>
> With always-ordered formats, there just seems to be less room for
> error.
>
> Just my 2c.
>
> - Chris
--
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
