Hi!
Sorry, this post turned out long. But hopefully interesting anyway.
On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote:
You cite an example very similar to what Dolphin does, and we could do with
SIXX.
> Dolphin serializes things not to avoid the image but to allow packaging.
> SIXX could do the same for us.
[SNIP]
> If we had something that could read and rewrite Smalltalk code that
is truly independent
> of WB, then class methods would be nice way to store GUI designs.
Bill
Just wanted to chip in here - IMHO there is a loooong history when it
comes to how to "save" UIs. We have seen (and in many different
programming languages) various ways through the years:
- Build them with code each time we want them
Pros: Resilient against framework/library changes
Very readable and editable
Easy to "store" in the language (just save as a method)
Cons: Very hard to use as a "save format"
Has too much freedom if we hand edit it
I actually favor the above since I normally dislike UI Designer tools
:). But I can of course see the value of a really good UI designer (WB
Pro is one of the best I have ever used, and the one in VisualAge was
also superb).
- Save them in "dumb" data structures (like VW specs)
Pros: A bit resilient since it relies on a builder, but not as good as
code because it is just dumb data
Similar easy to store in the language
Cons: Not readable and editable
VW has used this for a long time and it is indeed pretty slick since you
just "store" it in a method. That is one very nice characteristic, and
if you have good options to dig into the builder after it has read the
spec - then having the spec be "non readable/editable" is not that
painful. But still, it is a bit of a serialization hack and ... doesn't
feel quite right.
- Save them in a more advanced (than an Array) non Smalltalk langauge
like XML
Pros: Quite resilient against framework/library changes, if grammar is
made to be declarative in style
Easy to use as "save format"
Cons: Get's complex and icky
Not so easy to "store" in language (a String literal?)
Not so readable and editable
IMHO using XML is "nice" (well...) for inter system and inter language
communications/interchange. But realistically, how much interplay can we
expect when we are talking about Morphic UIs? AFAIK the rest of the
world haven't been able to gather around a single format either. If
there indeed was a format that all the Gtk/Qts and whatnots out there
used - then by all means. But is there?
- Serialize (in binary or whatever language like XML etc) them as they
are in their object form and deserialize to instantiate
Pros: Simple as save format, just smack it out
Cons: Not resilient against framework/library changes, in fact very
brittle
Not readable nor editable
Not so easy to "store" in langauge (ByteArray? String literal?
Serialization (as in "storing the object model exactly as it is") IMO
almost only has drawbacks. It is very brittle when systems change and it
is not readable nor editable etc. I just don't like it at all :)
Ok, sooo... not sure if I made the Pros/Cons clear enough to be
understood here. Anyway, in my quest earlier to build Deltas and
Deltastreams I ended up investigating "formats" and then I created Tirade:
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
(sorry for lack of nice CSS there)
NOTE: Since those articles I have simplified it a bit - I scratched the
complicated "stack" logic around figuring out the receiver.
Anyway, Tirade is in short a very long cascade that only allows
arguments in literal forms. So basically Tirade doesn't serialize
objects - it serializes a *sequence of messages*. And then when we
"deserialize it" we replay those messages onto a receiver.
Thus, in syntax it is very Squeakish - it even uses the same number
parser etc as the Compiler does. But it is a very restricted subset of
Smalltalk which makes it fast and secure.
So, given the Pros/Cons above, let's see how Tirade would fit:
* Easy to read and edit: yes, it looks like Smalltalk, but without a
receiver to the left.
* Easy to store in a method: yes, quite simple, the easiest way may be
to save it as "Smalltalk" like this:
tiradeOn: recorder
"Create Tirade by sending messages to a Tirade recorder."
recorder message1; message2; message3
In that way you can still use senders/implementors etc of the message
selectors.
* Easy to store outside of the language: yes, trivial, and fast to write
and read
* Very resilient against framework/library changes if we use a
declarative style.
regards, Göran
