On Friday, August 2, 2002, at 06:46  PM, Andreas Raab wrote:

> Tim,
>
> It's unlikely that this would help too much.
It's entirely posible you're right.

>  For one thing, there are a
> few issues which are deeply buried within the morphic kernel (see my
> recent note on the problem of doing layouts when invalidating morphs).
> Fixing these problems requires *deep* changes to the morphic kernel (so
> deep that I could never convince myself to do it and rather upgraded my
> machine) or to write a complete (and incompatible) widget set.
The deep morphic stuff is something I'm not even going to try to comment 
upon; way outside my scope right now. However, not all situations can be 
remedied by resorting to Moore's law, for example I can't get a faster 
Acorn :-(, iPaqs are stuck as they are etc. So I hope there are things we 
can get around to doing. Besides, morphic has been around for quite a 
while and has accumulated a lot of cruft and it is probably time to at 
least imagine possible benefits of replacing it with a cleaner rewrite. 
Burn the class tree!

> Secondly,
> once you start going down that path you will start using these amputated
> morphs until somebody comes who wants to use a whizz-bang feature and
> will revert it to the fully-fledged version and at that point you're
> back to square one.
Well exactly. Certainly one could argue that that results in no net gain 
and a lot of work wasted but I posit that a moderately well worked out 
DumpTextMorph would in fact be smart enough for a very large range of 
typical usage. Thus one can make a counterclaim that for a lot of the time 
there would in fact be a benefit.

>  Thirdly, a number of problems (like recreating
> menus; invalidation policy deficiencies) cannot be solved by any of
> these techniques anyways and what is needed here is a fresh look to
> understand under which circumstances exactly we can avoid any additional
> workload.
Oh absolutely. I was careful to refer to 'morphic applications' for 
precisely this reason. It's very likely that a lot of time can be saved by 
appropriate caching in places that are nothing much to do with the actual 
morphic code. Indeed there are places where that might improve behaviour 
and not just performance. One potential case I can think of is menu 
opening where 'old' Smalltalk used to keep the menu around in text panes 
and this meant that the menu popped up with the last chosen option already 
to go again. I found this very pleasing if I remember correctly. A bit 
more thought could make it pre-select paste after a copy/cut for example - 
perhaps a good thing, perhaps not.
tim
--
tim at sumeru.stanford.edu
"Oh Bother", said Pooh as the WorldMenu refreshed too much screen yet again