Eliminating that superfluous notification can be a performance improvement. 
However, whether or not the notification is sent should not make a difference to
correctness (I think).

At the time the notifications are about to be sent, the old and new value (on
which the decision whether to sent notifications would be based) are not known
(the values need not be provided in a call to prepareSet, might be obsolete by
the time the notifications are about to be sent, and the code that decides
whether to send notifications cannot easily read the old value safely in a
multithreaded scenario).  A possible solution would be to change prepareSet to
do nothing if oldValue equals newValue (and leave the bound listeners empty). 
However:
1  This would require every caller of prepareSet to supply oldValue and
newValue, which is highly undesirable.
2  This can easily be done by client code (that is willing to make available
oldValue prior to setting newValue): if oldValue equals newValue, do not perform
the sequence of calling prepareSet, setting the new value, and calling
BoundListeners.notify.  (Watch out that at least C++
com::sun::star::uno::Any::operator== and Java com.sun.star.uno.Any.equals have
slightly different semantics, when doing the check for equality of oldValue and
newValue).
3  This could of course also be offered as an additional helper function at
ProperytSetMixin:
  bool prepareSetIfDifferent(propertyName, oldValue, newValue, boundListeners)
which would require oldValue and newValue to be set.

Ocke, in light of the above, would you agree that this issue should be solved in
the client code, or would you prefer a corresponding helper function bool
prepareSetIfDifferent(...) at PropertySetMixin?

Hi Stephan,

I would prefer a corresponding helper function bool prepareSetIfDifferent(...)
at PropertySetMixin so that we could avoid duplicate code :-)


- Ocke

Reset assigne to the default "issues@openoffice.apache.org".