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 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. 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.
So given that, you're dealing with first-class objects all the
time. 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. 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.
thanks,
-C
[1] http://netjam.org/spoon (main site)
[2] http://thiscontext.wordpress.com (blog)
--
Craig Latta
www.netjam.org/resume
+31 06 2757 7177
+ 1 415 287 3547
