Hi Luc,
Le jeudi 22 août 2013 21:19:00 UTC+2, Luc a écrit :
>
>
>
> Metadata is part of the Clojure environment and part of the value domain
> it handles.
> Why should it not be transmitted along with the value ?
> If the receiver is not written in Clojure it may be questionable an
> probably not
> very useful to transmit it but otherwise ?
>
All you're saying is right, as long as you own your data and communicate
between clojure programs, any "hack" is just particular design solution.
>
> > when you exchange data in json, for example, you're not providing
> object > class in the stream
>
> What's an array then in Json ? Somehow it has to end up in a concrete
> type.
> If both ends are written in Clojure, why not convey the type ? What harm
> can it do ?
>
> Records are essentially immutable maps. I would carry the type of record
> as
> metadata and let the other end decide to instantiate it or not under the
> given
> record type. This is a personal choice based on the context (same app at
> both
> ends or maybe not, ...).
>
> Again if the receiver is not written in Clojure obviously it does not make
> sense but if read the OP post correctly, it's not the case.
>
I am not advocating for no types and meta in edn, in fact edn provides
custom tags to do just that : read what you want from data and map it to
your design.
As you said, you end up with concrete types : string values map to your
language types (long, arraylist, hashmap, etc).
When I was saying, that we *should* not need to convey types and meta, it
was more in a language agnostic situation (ex: client agnostic API)
>
> > > - If you just want serialization to reload hot data or use some kind
> of RPC > mechanism over the wire, than I think edn is not the right tool.
> >
> Uh ? "hot data" ? Here we exchange thousands of messages per hour using
> Edn. We care little that the data is cold, medium or hot. It simply
> works..
> Configuration data, live data,..
> We added a few extensions to support some objects as is but very little.
>
I used the term "hot data" to mean data with all your meta and states, like
Jim is doing for his chess game. He persists a game state to reload it fast
without too much reprocessing.
Don't get me wrong, I'am not against any use of edn, in any situation. If
it solves you're problems, than you're good to go.
Regards
Kawas
>
> RPC stuff is hard to work with and couples both ends a lot. Edn is much
> more
> flexible by allowing you to decide when and how you want to instantiate
> concrete implementations.
>
> Any (easier) alternative you can come with ?
>
> Luc P.
> > > Cheers
> > > Le jeudi 22 août 2013 13:24:33 UTC+2, Jim foo.bar a écrit :
> > >
> > > Hi Meikel,
> > >
> > > this is funny! I thought about this approach but I originally
> considered > > it to be a clever hack rather than the official way to do
> this...Since I > > can't test it yet with my record , I hope you don't mind
> me asking another > > question...
> > >
> > > there is no need for print-dup bound to true here, right?
> > >
> > > thanks a lot for your time :)
> > >
> > > Jim
> > >
> > >
> > > On 22/08/13 12:00, Meikel Brandmeyer (kotarak) wrote:
> > > > > (defmethod print-method Foo
> > > [foo ^Writer w]
> > > (.write w "#my/foo ")
> > > (print-method {:a (:a foo) :b (:b foo) :c (:c foo) :meta (meta foo)}
> w))
> > >
> > > (defn foo-reader
> > > [foo-data]
> > > (with-meta (map->Foo (dissoc foo-data :meta)) (:meta foo-data)))
> > >
> > > Read with:
> > >
> > > (edn/read {'my/foo foo-reader} ...)
> > >
> > > Printing might be optimised a bit. And the :meta key could be made
> more > > robust. (records may contain arbitrary keys.)
> > >
> > >
> > > > > -- > -- > You received this message because you are subscribed to
> the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com<javascript:>
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com <javascript:>
> > 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+u...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/groups/opt_out.
> > --
> Softaddicts<lprefo...@softaddicts.ca <javascript:>> sent by ibisMail from
> my ipad!
>
--
--
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/groups/opt_out.
