[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
New Model structure
- To: <mark>
- Subject: New Model structure
- From: Eric Dean Tribble <tribble>
- Date: Sun, 29 Oct 89 17:52:58 PST
- Cc: <xtech>
- In-reply-to: <MarkS.Miller'smessageofSun>,49 PST <8910300032.AA02837@xanadu>
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
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
OK. Thanks. End of thread (unless you really feel like arguing :-)