It's important to remember what important about MVC (and MVP).  With MVC,
you enable the independent evolution and deployment of an object and it's
representation in some context (in this case a GUI).

MVC was designed in a time when much less was known about prototype based
languages, delegation, and context based behavior.  So, MVC has it's
limitations.  And, because the base language/VM (Squeak) lacks some of these
advanced language features, Morphic also suffers a bit.  But, Morphic itself
imposes no limitations wrt using an MVC design.  Thomas makes some excellent
points along these lines.

I don't think anyone on this list would argue that model-view separation is
not a good thing, it's just that Morphic lives in this sort of language
purgatory that makes neither MVC, nor Morphic ideal (but based on where
languages and UIs are headed, I'd say Morhpic is a better bet).

- Stephen

> -----Original Message-----
> From: Bob Hartwig [mailto:bob at bobjectsinc.com]
> Sent: Tuesday, March 27, 2001 5:12 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: Difference between Morphs and bad programming
>
>
> Interesting observation Ross, I share your concern.  The
> definition of "bad
> programming" is highly dependent on the scope and purpose of the system
> being programmed.  For a medium- to large-sized system, or a system that
> may need to be ported across dialects, mixing the UI and model is a
> disaster.  For a quick proof of concept or exploratory simulation, it
> probably isn't.
>
> To me, one of the great things about Squeak and Morphic is that they
> support both modes of development.  You can write your model in Smalltalk
> and put a Morphic UI on top (as I did in SqueakAmp -
> http://www.bobjectsinc.com/squeakamp ), or you can just go nuts in Morphic
> to get some cool smaller-scale stuff done quickly.  I do share your
> concern, though, that Morphic doesn't actively encourage the former, and
> IMHO more powerful mode of development.
>
> 	-Bob
>
>
> At 12:28 PM 3/27/2001 -0800, you wrote:
> >I must be missing something.  I've read a bunch of documents on morphs,
> >including why they are "way cool".  I've played around with them a little
> bit.
> >
> >It seems to me the argument for separating the model from the
> >view/controller is a good one.  And it seems to me the "cool"
> thing about
> >morphs is that they don't separate these things.
> >
> >All the buzz at least suggests that morphs represent some kind of
> >mind-shift from the usual way of doing things.  My mind seems
> not to have
> >shifted!  Could anyone help me out on this one?
> >
> >Do you agree that morphs include both the GUI and the model?  Or
> are morphs
> >intended to be a more capable GUI layer that will still operate
> in tandem
> >with underlying, non-graphical model classes?  If not, why is combining
> >model and GUI a good thing?
> >
> >Regardless of the first point, what is or are the core
> innovations of morphs?
> >
> >
>