Craig, Fantastic wishlist!
However, maybe because the synthetic nature of the proposal, 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? -- Cesar Rabak Em 14/02/2011 08:14, Craig Latta < [email protected] > escreveu: Hi Göran-- Thanks for the summary! I think there's another option as well. If you have... - the ability to transfer methods directly between live systems, without having to recompile source code - a way of specifying groups of methods ("modules"), and prerequisite relationships between those groups ...then you can... 1. Compose a GUI using a direct-manipulation editor. 2. Represent the state of that GUI with an object (which probably makes references to several other objects). 3. Create a method that refers to that object. (One way to store the object would be as a class variable.) 4. Transfer that method to another live system. The method is probably little more than asking the GUI object to render itself. If you want to know more about how the GUI object was created, you can ask it that too. The method's module specifies at least of the GUI framework as a prerequisite. You can have as many different GUI frameworks around in a system as you like, perhaps introducing some as others are phased out. Perhaps message interfaces common to all of them will emerge over time. All along the way one uses familiar tools to inspect and change state and behavior. Although source code isn't necessary for transferring behavior from one system to another, it's all still readable. This scheme is readable, editable, easy to store, and amenable to framework change (the four things you were after). thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
