Em 15/02/2011 20:28, Craig Latta < [email protected] > 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
