Craig, If I am following this correctly, it's over-engineered and will back fire. You are setting up some of the same mistakes that were made in SmartReferenceStream, only with both sides involved. This is a simple problem calling for a careful solution.
Dolphin has this right: version the serialized streams, and the consumer either knows how to read it or not; errors result in the latter case. What you are doing *could* be ok with the developer of both systems on hand to monitor it, but that will be rare. In fact, one might assert that serializers are useful precisely when one of the parties is absent: otherwise one would simply pass the object and be done with it. What you want are tools that make it easy to write the converters (which belong in the affected classes, not the serializer - another SmartReferenceStream oddity). SIXX *might* avoid some of this by focusing on messages rather than instance variable layout, but even then, some attention to legacy data would be required. Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Craig Latta [[email protected]] Sent: Thursday, February 17, 2011 8:04 PM To: [email protected] Subject: Re: [Pharo-project] A new GUI visual designer Hi Göran-- > Thinking about this a bit more I realize one interesting aspect: > > Your stuff is basically low level serialization support - right? It is, but what makes it interesting is that it's *interactive* serialization; the producing and consuming systems interact. Traditionally, you serialize to a file, and at the time the consuming system reads it, the producing system is long gone. The consumer can't ask the producer anything about it if finds something confusing, and the producer can't take any information about the consumer into account when creating the bits. Speaking of recipes, imagine following a recipe from a cookbook. You might wonder if you can leave some ingredient out (because you forgot to go the store), but you're on your own figuring that out. All you have is the recipe. But if the author of the recipe were there with you, telling you what to do, you could just ask. And the author might not even bother mentioning the missing ingredient, because he can already see when you start that you don't have it. It's this sort of synchronization that Naiad (Spoon's module system) supports. It's important when transferring individual method literals, entire methods, and entire modules. It's all messages going across the wire between producer and consumer, and their precise content may vary significantly from one consumer to another. Expecting one set of bits to convey the correct thing to all consumers, in a system as dynamic as Smalltalk, always struck as me a bit crazy. :) > So... it all boils down to what kind of object model you pick. Now... > come to think of it - readable and editable? Not sure how you mean > there... I meant it in the sense that I thought you did... the way I'd store GUI information is even more readable than viewspec arrays or XML because it's just the original objects from which we derived the viewspecs and XML. It's more editable for the same reason; we can use the same powerful inspectors and browsers that we used during development. > ...counting the designer tool as the editor is kinda cheating :) Hey, if it's useful, why not? :) > One nice way to make a GUI description to be very robust against > change is to let it be the representation of "a sequence of commands > aimed at a builder API". Thus, the actual UI framework can change all > it wants, as long as the builder API still works. > > So, if your object model is such a "command sequence" then I agree, it > would be as robust as the same thing in Tirade. But... if your model > is the actual built UI then I don't agree that it is as robust - > supporting "migration" from one object model to a new one is kinda > complex. Well, builder APIs can change, too. But sure, I'm not attached to any particular GUI object model, or style of model (declarative or otherwise). I do think, though, that using the actual built UI becomes an interesting option when you have live synchronization. I view the complexity as similar to writing correct "postCopy" methods (not too bad). You could ask a UI object to spit out builder commands, for example, as I suggested in an earlier message. Builder commands could be an exchange format, used occasionally when necessary. -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
