Em 15/02/2011 20:28, Craig Latta < craig@netjam.org > escreveu:
Hi Cesar--
Fantastic wishlist! However, maybe because the synthetic nature of the proposal... Well, I'm cheating here, because I've already implemented the givens (live method transfer and modules). See [1] and [2].
I see. I'd a suspition but was too busy when I wrote my reply to check on Spoon...
...I think I missed something: How can a "...a method be transferred to another live system." as per your "4." and "Represent the state of that GUI with an object" and even be "amenable to framework change" simultaneously? When you're done composing a GUI with an editor, you've got an object that represents the GUI, typically a hierarchy of widgets and event-handlers (perhaps similar to a VisualWorks viewspec, but an original object instead of a transcription of one). The precise nature of the objects in that hierarchy depends on your GUI framework.
Yes! this was the part that triggered my attention!
But whatever it is, you can transfer a method using it to another live system, because (at least in the stuff I wrote) you can transfer any method no matter what its literals are.
I see, but then we have to check if a given message send may end up in MNUs, right?
So given that, you're dealing with first-class objects all the time.
I think you're partially right here: your implementation scheme gives us an impression of 'first-class' objects. If underlying framework is different enough to have the methods that when called end up in Debugger, I see this only as a kind of Grease or similar mechanism (perhaps SIXX with a bit more of semantics). I think I can see this grand vision working if some kind of 'equivalence' of widgets could be produced so that a Morphic based GUI design could be used in [say] wxWidgets based {Pharo,Squeak}.
That's what makes this scheme adaptable to GUI framework change. You can examine GUI objects, ask them to convert themselves to another framework's structures, etc. with familiar Smalltalk tools.
I understand that in order that be possible they would need to answer to the become: protocol and need to have in the target image both the frameworks, right?
There are no "dead-data" formats to worry about, because all method literals get transferred as part of fundamental system behavior, without any special consideration by the GUI framework.
Well, this seems to me more or less neutral for being compelling. The representation of a GUI design, if we get a good format, could be one of the best contributions we could do to the programming comunity. As we're learning, (slowly) but it is part of our growing pains, Smalltalk does not lead the way in the design of GUIs anymore. We need to fit in an industry. The same way we needed to accomodate the ORM in order to be able do do CRUD in Smalltalks, we need to go to the GUI side and go for a more aligned with the mainstream technology and practice. With the caveat I may still have not undertood your proposal in full, I see that in limit, the right mapping would be to the host system GUI primitives, so the whole issue of having to design a specific widget hierarchy would vanish. Correct? regards, and keep the research in Spoon! -- Cesar Rabak