That makes sense. In fact, I suspected the answer had to do with late binding. That's why Nextstep and Objective-C was IMHO the best development environment. (Smalltalk, at least Squeak, UI development is still a bit rough but I can see the potential for the same ease-of-development).

From: Mark Guzdial guzdial@cc.gatech.edu

Dan Olsen talks about this in his new book on "Developing User Interfaces" (Morgan-Kaufman, 1998). I don't think I grok all the subtleties, but I'll try to relate the story. The self-reflective and late-binding nature of Smalltalk allows you to create views that are more de-coupled from their models. For example, when a textbox sends #getText to its model, it doesn't care what the model is, as long as it can respond to getText -- you can even swap the model at run-time, and as long as the message is answerable, it all works. Olsen contrasts this with C/C++ where the compiler requires the model and view to be linked together at compile time, the types have to match, etc. Java can do this de-coupled model-view, too, but it had to invent (overly-complex, IMHO) inner classes to make it work.

Jim

The self-reflective and late-binding nature of Smalltalk allows you to create views that are more de-coupled from their models. For example, when a textbox sends #getText to its model, it doesn't care what the model is, as long as it can respond to getText -- you can even swap the model at run-time, and as long as the message is answerable, it all works. Olsen contrasts this with C/C++ where the compiler requires the model and view to be linked together at compile time, the types have to match, etc.

I have to relate an anecdote from the early days. We were using Smalltalk-76, the first Smalltalk that performed well enough to support serious software (it had the same engine as Smalltalk-80, and a simpler body ;-).

There was a student (I can't remember who this was) on one of the Alto's in the corridor who was having fun implementing a Fraction class (there wasn't one built in). He came over and asked me to give him some help because he had gotten things in such a shape that something was preventing the screen from redisplaying successfully when he proceeded from the debugger.

I went over and started to paw around, and discovered fairly soon that the bottom-level call on BitBlt was recieving Fractions as parameters, and was therefore failing. As I looked around to see how that happened, I was astounded to find that the entire browser in question had fractions in practically every point and rectangle in all its views and subviews. I asked him about this, and he said, "I just reframed it, but maybe it was because I made divide return a fraction." I said, "Hmm, maybe so. What do you send to a Fraction to get the integer part?" He told me. I added the coercion to BitBlt's fail code, and the whole thing proceeded to run just fine when I restarted the method. I remember feeling almost dizzy on the way back to my office.

- D