On 14 February 2011 09:59, Sven Van Caekenberghe <[email protected]> wrote: > 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 ?
No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for reading/writing source streams. Just don't use ascii, then you won't need to escape non-ascii characters. :) > - 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 > > > -- Best regards, Igor Stasenko AKA sig.
