> - Adding and removing listeners is a cheap operation AFAIK. "Cheap" is relative and cheap operations have a way of adding up to become expensive. More importantly, removing the listeners in an unsynchronized fashion, as is currently done, opens a window for events to be lost during the period in which no listeners are registered.
> >> Certainly FigState is not a good design. > >> > >> We should only be adding removing the specific listeners > >> we need to at any one time. > > ...but it leads to highly complex code. Hence we (I?) decided > to go for the FigState solution ever since. It's hard to comment on this complexity in the abstract, but I'm not sure I understand it. There are two types of things of interest: 1) attributes on the model element, which are all covered by a single listener and 2) associated model elements which affect the appearance in some way. For #2, is it more complex than adding a listener when we receive an relevant AddAssociation event and removing a listener when we receive a RemoveAssociation event? > (2) Can we maybe buffer part of the model to reduce querying > the model? Caching parts of the model would require a cache synchronization protocol. To even make it worth considering, accessing the cache in memory would need to be significantly faster than accessing the elements through MDR (also in memory). Without having done any measurements, I'd guess that this is unlikely. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
