all I'm trying to do is to provide a uniform mechanism to save/load
game-states across my 2D board-games. Everything works just fine without
that trick for most games but chess is peculiar (or my implementation is
peculiar if you like) because in order to implement castling/enpassant
moves without global nastiness I had to attach some metadata to every
piece that moved.The notion of 'having-moved' though is not necessarily
part of a piece itself and that is why I thought meta-data would be
appropriate and wouldn't affect equality between pieces that have moved
and ones that haven't. The same principal I think applies to being alive
or dead...logically speaking, a bishop is always a bishop, it's only
when the game starts that suddenly 'alive' and 'dead' matter...
anyway, the way I've currently set it up it works for all games...my
chess does exactly what Meikel showed earlier but the other 2 games work
without that...btw, java serialisation always worked but I can't recall
whether it preserves metadata...
thanks everyone - I can't believe how much I learnt through this post
and some poking around on the web :)
clearly, YOU ROCK!
Jim
ps: now that I've explained the use-case can anyone recommend any
alternatives?
On 22/08/13 16:46, kawas wrote:
Jim,
This is indeed a hack and not a best practice, maybe you're not using
the right tool for your problem...
- If you want to exchange data (think values), you should not be in
need of keeping types and meta data
when you exchange data in json, for example, you're not providing
object class in the stream
- 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.
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 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.
--
--
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.
