I understood yesterday that Spoon doesn't send objects to be recreated on the other side of a remote message, it sends information about objects. It encodes objects.

I see tags go over the wire and the tag types are related to classes in the EncodingClasses classvar in MessagingSession class>>initialize.

OK, a tag called methodTag goes over the wire. Now what? It is connected in the dictionary to CompiledMethod. OK, we are going to make an instance of a compiled method on this side from the info coming over the wire. It's a little generic, isn't it? Don't we need to be a little more specific about what's in it? All those byte codes and literals?

Then it occurred to me that a new instance of CM could be populated... with the literals and material that are in a CM. What would we do that with? The whole class category in Spoon called LiteralMarkers. I'm guessing the markers go over the wire after the tag. Then they get installed into the CM. Bang. You've created a CM from a blueprint of one.

That' blew my mind. CM's always seemed immutable. Seems I've just never spent much time with CompiledMethod>>#newMethod:header: Let's just make one with a bag of literals.

And if we can make CMs from a stream of information, then we can make anything. Classes are just collections of CMs with some variables.

Here's were we do just that: we make a CM and fill it full of literals from literal markers.

MethodEdition>>#method "Answer the method I prescribe in the local system."

| method |

*method* := ( *CompiledMethod* newMethod: (endPC - initialPC + 2) header: header).

1 to: literalMarkers size do: [:literalIndex | *method* literalAt: literalIndex put: (literalMarkers at: literalIndex) *literal*].

.. snip ...

^method

It seems to me these tools of tags and markers are a complete way to describe classes and instances. They can be stored as data and then re-instantiated on need. And I guess you could take a snapshot of any object or set of objects to have a history or version record.

Have a nice weekend,

Chris