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 _______________________________________________ Spoon mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon |
Thanks, Chris, for sharing your explorations with us! I really enjoy
reading your posts, even if I normally don't comment on them. > 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. My impression is that BlockContexts are the trickiest things to serialize. I don't know if Spoon can move computations from one image to another, but I don't think this would be needed for Craig's goals. -- Jecel _______________________________________________ Spoon mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon |
In reply to this post by Chris Cunnington
Hi-- Chris writes: > 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. Yep! Jecel writes: > My impression is that BlockContexts are the trickiest things to > serialize. I don't know if Spoon can move computations from one image > to another, but I don't think this would be needed for Craig's goals. Yeah, not needed for providing a history system, but Spoon can do this. I also have a way of versioning arbitrary objects in the system, not just classes, methods, etc. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 _______________________________________________ Spoon mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon |
Free forum by Nabble | Edit this page |