The only difference between Model and Object is that each Model has its own
dependents collection, rather than using a global Dictionary. And EventModel
instances likewise have their own dependents dictionaries. But both protocols
will work with any Object, since there are globals to hold these dependencies
as well.

So (for instance) you can use the usual MVC protocols with any object (even
non-Model ones); if your object that has dependents does not override
#myDependents (which Model overrides), you'll get an entry in the global
(Object class variable) DependentsFields. Likewise for EventsFields and
#myEvents. And the only overhead from not using Model or EventModel is an
extra lookup in these dictionaries.

There are at least two publish/subscribe frameworks in Squeak: the
changed/update:/Model ("updating" category) one from classic MVC, and the
when:sendTo:/trigger:/EventModel ("events" category) one, which is faster
(because it has less overhead). The Pluggable* components use the old one
(that is, Model).

Morphic is, in general, agnostic with respect to notification. Some Morphic
classes use the classic MVC notification (notably the Pluggable* ones, for
compatibility with the MVC GUI). Most poll in their step methods rather than
get notified. Some do both.

But it's certainly not required to have a separate Model for each Morph (in
fact, that's probably the exception, other than for the more old-fashioned
(classic?) UI elements like browsers). Many Morphs are their own model.

Since Morphs don't require notification in order to change themselves (they
can poll instead if they want, using #step), there's more flexibility in
Morphic UI design: you can use notification, or not.

<quote>
There is a class Model (yet another use of the word!) which is almost
identical class Object from which it inherits. The main difference is
that a collection of the dependents of instances of Model is held in
an instance variable. This organisation has the benefit that if you
destroy the master, the dependents collection will be automatically
destroyed and, provided no other objects reference these same
dependents, the dependents can be garbage collected automatically.

If, in contrast, a master that does not hold its own collection of
dependents is destroyed, its dependents may still be referenced by
class Object. This may cause the dependents to persist even when no
other references to them exist and they are effectively useless. In
the worst case, a steady stream of such happenings can cause a memory
leak - the memory becomes filled with useless 'dead' objects or
zombies. Over a long period of time, any object-based system may
become clogged and refuse to run. Indeed, during prototyping of the
course, the Course Team stumbled across the odd dead zombie frog. To
avoid this voodoo-like fate for an object, many programmers who use
the dependency mechanism prefer to subclass from Model rather than
from Object   You may like to look at the model class using the class
browser in the next practical session. If you prefer to stick with
models that are subclassed from Object and you expect to run your
program many times, an alternative is for you to give the master
objects a finalisation or release method that removes all dependents.
These methods use messages such as removeDependent: when closing the
program.
</quote>