Posted by
Schwab,Wilhelm K on
Feb 18, 2011; 1:04pm
URL: https://forum.world.st/A-new-GUI-visual-designer-tp3067111p3312616.html
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:
[hidden email] [
[hidden email]] On Behalf Of Craig Latta [
[hidden email]]
Sent: Thursday, February 17, 2011 8:04 PM
To:
[hidden email]
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