Hi Göran, On 14 Feb 2011, at 00:18, Göran Krampe wrote:
> 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 :) Excellent summary/writeup ! > 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. Tirade looks cool, very nice idea, simple and powerful. Nice name too. Some questions: - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? - there does not seem to be a way to deal with non-ascii strings like 'Göran', shouldn't there be something like JSON escapes ? - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ? - has this since 2009 been used anywhere ? - how about inter Smalltalk interoperability ? Sven
