New Model structure

[Eric Dean Tribble <tribble>]

Why should it be a set?  (I'm neutral, but I want a reason to go
      one way or the other).

   Sets are simpler, so if it can be both, it should be a set.  Looked at
   another way, it should be a bag if the model needs to record each
   dependent once for every time the dependent registers itself. 

We'll almost certainly need to implement a special Dependents
Collection, for optimzation (both space and speed).  The dependents
collection needs to add, remove, and iterate over elements quickly.  I
don't want to pay for a duplication check on every add or remove of an
element.

   As opposed to simply recording which dependents have registered
   themselves.  The only circumstances in which this would make sense to
   me is: if dependent D registers itself with model M three times, and M
   changes, broadcasting update record U to its dependents, then M must
   send U to D three times.  I can't imagine why this would be.

Consider the Set version of this:  If I add a dependent twice, then
remove it once, should the dependent still receive updates?  I think
the least surprising answer is yes.  

Besides, I just thought of a style of usage that might cause this situation.

   Besides, I want to get away without us having to have a class Bag, so
   I've got a vested interest in saying it should be a Set.

Well since we need a separate class anyway (subclass of Dependent), we
don't need to invent any Bag semantics (unless I come up with an
interesting use).

OK.  Thanks.  End of thread (unless you really feel like arguing :-)
dean