Hi Tom,
- 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.
Yes, that is a potential problem.
This problem may occur if the model changes when registering listeners
again, not when removing.
>> 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.
And there are many of these sometimes ...
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?
Yes, you also have to register the listener in the first place, i.e. on load
of the project.
If you add something, then you mayhave to add a lot of other listeners, too.
And if you remove e.g. the operation of a class, then you also have to
remove the listeners to the operation's parameters & stereotypes.
(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.
I did not mean this as a speed improvement, but as a way to prevent the
problem mentioned in the beginning of this mail.
I.e. similar to Swing having a model for e.g. a combo.
Maybe this is not a good idea...
PS:
I still intend to work on the Notationproviders, to split off most of the
complex listeners code into the NotationProviders, i.e. that the
NotationProviders listen to the modelchanges themselves, and update the
FigText.
Any improvement in the way Figs listen to modelchanges should consider this!
Regards,
Michiel
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.8/415 - Release Date: 9/08/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
