[Chicago] Help wanted: Python/JS Reflection library

[Ian Bicking]

Pete wrote:
> {
>   "__class__": "Foo",
>   "color": "red",
>   "size": 42,
>   "quux": {
>     "__class__": "Bar",
>     "drink": "whiskey"
>   }
>   "when": {
>     "__class__": "datetime.date",
>     "day": 4,
>     "month": 4,
>     "year": 2007
>   }
> }
> 
> This is done entirely via introspection/piggybacking on existing serialization 
> methods - there's no explicit support from Foo or Bar required.  The idea is 
> that some library in language L can take this data structure, which consists 
> solely of JSON datatypes,  and build a corresponding data structure in its 
> native types/user-defined classes. And vice versa.
> 
> This isn't code shipping - I'm assuming the same person writes the code on 
> both ends.  If you forget to define a Foo in L, that's your bug, not 
> mine. ;-)  It's nothing more than a convention for getting object-oriented 
> data across language boundaries.  Maybe I'll call it Esperanto.[0]

I think "class" is too overloaded a term.  Or perhaps "type" is a 
slightly less overloaded term that might be more applicable.

>> Messages can work, which is what JSON is typically used for.  Messages
> 
> 'Message reflection' might a better term than 'object reflection'.  The idea 
> is to provide some helpers that let you load up the message into an existing 
> class definition.  It's no more featureful than a bunch of functions that 
> operate on plain-old JSON data structure.  Just adds some sugar.

Maybe a useful way of thinking about it is that you should really be 
communicating "value" objects.  There might be kinds of values beyond 
the basic JSON types (well, certainly there would be), but they feel 
somewhat similar.  That is, they don't really have behavior, and often 
they are immutable (or close to it -- perhaps immutable at least by 
convention).  So you might have a color object like:

   {"type": "color", "r": 255, "g": 0, "b": 0}

It means something other than just a dictionary, or even more than just 
an object that happens to have .r, .g, and .b attributes.  A date object 
is similar.  Python has a bunch of these kinds of objects; I think it 
tends towards the functional than many other dynamic languages. 
Functional languages are purely this kind of object -- especially when 
you start dealing with generic functions, where objects don't appear to 
carry around functionality with them.  I think pattern matching (which a 
bunch of functional languages have) also kind of acts like generic 
functions in the same way.

Hmm... but what does "color" mean?  Seems kind of obvious, but clearly 
there could be other kinds of implementations (e.g., h/v/s, or even 
trivial stuff like red/green/blue).  You could kind of be like XML 
namespaces, and do:

   {"type": "http://purl.com/color", ...}

There's a kind of unambiguous nature to that, and conveniently 
self-describing.

Now I'd say just implement pattern matching in Javascript and Python 
(and whatever else) based on this, along with some conventions for 
message communication (probably just built on HTTP), and have at it!

Along these lines, you might find Roberto Almeida's projects 
interesting: http://dealmeida.net/projects/ -- specifically jsonstore 
and webskine.  I believe most of the UI is really in Javascript.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
             | Write code, do good | http://topp.openplans.org/careers