So typically we create schemas, mime-types, etc for our objects when we're communicating to another system about objects.

The document usually defines data structure of the objects for serialization purposes with no recording of the object's methods. All I am left with on the client are effectively structs with no methods.

So for example let's say I have multiple classes and let's say those included an Account and an Order. Let's also specify that orders are tied to an account. Now let's say I have a client who wants to fetch a certain order that's related to an account from a distributed service that provides this information. I could code all of the searching, scanning and other types of logic into the distributed server and make the client rely on it for everything it could want to do (extreme RPC). I could just write code to scan through object graphs on the client, forcing each client with type of interest to replicate the code. I could create a library that contains common functions. But what I'd really like, is the ability to replicate methods on the object to the client as part of the contract. The client would not only know the data structure of the distributed object, but could also call and execute operations on the object that was distributed with it.

Is there any system out there that serializes operations\code along with data structure for objects? Ideally it shouldn't just be an RPC client stub that invokes operations on a server.

  • Sending code to the data is a vary map-reduce sort of concept. It's not OOP though.
    – Sign
    Sep 25, 2014 at 16:27
  • @Sign how would sending code implementations along with the data structure in the contract for the object not be OOP? Sep 25, 2014 at 17:34
  • It isn't sending the data it is only sending code.
    – Sign
    Sep 25, 2014 at 17:59

1 Answer 1


I think the reason this isn't done more often is because you're sending code along with your data, and therefore you no longer have total control over the code. Maintaining security over your operations would be a real challenge. This is not true of data, because you can sanitize, validate and authorize data, using code that you can control and secure.

Code is also not homogeneous, in the same way data is. Many different programming languages and techniques are used to create data processing systems, but the data remains in essentially the same form. This is especially true of XML data. XML data is specifically designed to be systems-agnostic; you can process it on any system with and XML reader.

If you want to look for a live example of code as data, you need look no farther than Lisp. Lisp has a deep philosophy of "code as data." In "The Nature of Lisp," the author explained this distinction by pointing out that you can translate any programming language to XML, transmit it over the wire, and execute it:

<define-function return-type="int" name="add">
        <argument type="int">arg1</argument>
        <argument type="int">arg2</argument>
            <add value1="arg1" value2="arg2" />

So all you have to do is send the source code in your transmitted object, compile it at the target, and execute it against your encapsulated data. :)

Your "serialization of code" then boils down to "include the necessary source code to process this object with every packet of data you send." I think you can see how this can quickly become very unwieldy. If you're going to transmit programs to a remote system that will operate on data you send it, it makes more sense to transmit those programs to the remote system ahead of time, install them, execute them, and then send your data.

  • This is pretty close to the idea for me, however I'm thinking of a system where the code is included in the schema or contract only. The objects then need no representation of the code for each payload. Sep 25, 2014 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.