On Nov 24, 12:42 am, Michael Wood <esiot...@gmail.com> wrote:
> Hi
>
> On 24 November 2010 04:43, Zach Tellman <ztell...@gmail.com> wrote:
>
> > 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
>
> I don't think he's talking about backwards compatibility at all.
Chris raised the issue of breaking a format by adding keys, but that
will happen no matter how the format is ordered. I just wanted to
make sure that was clear.
>
> Assume you have two C structs that you need to interoperate with. The
> first has a few fields and the second has many fields. If you specify
> the format with a map, then when you serialise your Clojure data, the
> smaller one will create the values in the order you specified in the
> map. The larger one will be in some arbitrary order which depends on
> Clojure's implementation and will likely not match up with the actual
> struct definition.
>
> Or to put it another way, say you have many structs. The first
> several have few fields, so you happily use maps to specify them.
> Everything works fine. Then you get to a larger struct and you find
> that your fields land up in the wrong part of the serialised output.
>
> I haven't looked at Gloss yet, so maybe this isn't possible for some reason?
I feel like I must have done a poor job describing the ordered-map
mechanism earlier. This codec is fine:
(defcodec c {:a :int16, :b :float32})
as long as Gloss is on both sides of the encoding and decoding, or if
the default ordering is coincidentally correct. However, if we want
to invert the position of :a and :b, we use ordered-map:
(defcodec c (ordered-map :b :float32, :a :int16))
This codec still consumes and emits standard Clojure maps, it just
makes sure that the values are encoded in a particular order. The
frame is the only thing that has to change to make the encoding
explicitly ordered; everything else can continue to use unordered
hashes without concern.
I think this solves the problem you describe, but maybe I'm
misunderstanding you.
Zach
>
> > [...] 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.
>
> I have used Python's struct library a few times (and perl's
> pack/unpack once or twice), so I'm sure Gloss would be useful for the
> same sorts of things.
>
> --
> Michael Wood <esiot...@gmail.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
