Imagine I started with e.g.

(defrecord Widget [^Integer id ^Integer version ^Integer amount])

but, whilst using records as my underlying datatype, I needed to hold
more metadata than a record definition allows - so I expanded
defrecord
into e.g.:

(deftable            ;; a table of Widgets
  widget-table     ;; name of var to hold extra table metadata
  Widget            ;; name of Record to be used to represent a table
row
  [                     ;; Record column descriptors with extra
metadata
   ^{:tag Integer :primary-key true} id
   ^{:tag Integer :version-key true} version
   ^{:tag Integer :mutable true} amount
  ])

Now I carry enough metadata to define my record type and an extra
'widget-table' value which holds the additional metadata.

Now lets say, I have a remote rich clojure GUI which uses some of this
extra metadata to drive its presentation.

In order to support dynamic addition of new tables to my system, the
GUI handshakes with the server, receives the metadata and then pulls
the corresponding data etc...

My problem is this:

I want to include functions in my metadata - e.g. I might want to
specify a version comparator function to allow tables to decide
whether a new version that they are presented with is actually more
recent than the one that they already hold. I might want to support
multiple primary or version keys by providing a pk-fn or version-fn
etc.

When I serialise the metadata from server to client, the client cannot
deserialise the metadata because the classes that were created
server-side to implement the functions are not present.

So, I've been trying to think of a nice way around this.

I should be able to writeReplace() my metadata object with a different
metadata object which carries everything that it needs to reestablish
itself in the client when it arrives - effectively to call the
deftable macro with the same parameters with which it was originally
called. Since it is a macro, these are easy to capture - of course
functions will have to be included by value and not by reference
within the original macro call, but I can live with that.

I thought that, before I did this, I should canvas the group for their
opinions on this. Has anyone done anything similar. Does anyone see
anything inherently wrong with this approach. Why do I feel slightly
uneasy about this approach myself ? etc...

thanks for your time,


Jules

-- 
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

Reply via email to