Non-final fireValueChangedEvent in PropertyBase classes an unfortunate design decision?

[John Hendrikx]

I have some observations about the method `fireValueChangedEvent` that 
most PropertyBase classes provide.

They seem to have several design problems:

1) It's specified that it is called internally when `set` is called 
(dangerous, as it can be overriden and not do anything breaking the 
contract of the PropertyBase classes).

2) When overridden, it does the exact same thing as `invalidated` 
(they're always called at the exact same time) -- perhaps `invalidated` 
was a later addition?

3) When called externally, it can trigger invalidation listeners over 
and over; there is no check if the property was actually valid.  It just 
fires all listeners ignoring the normal constraints.  Notifying 
invalidation listeners again when already invalid is the use case they 
were designed to avoid.

My problem with this implementation is primarily in the fact that the 
implementations of the PropertyBase classes are **forced** to call it 
internally, as otherwise classes which override this method would "miss" 
this "event".  But that isn't the only issue; I could just leave the 
implementation empty and call both that method and another method that 
does what I want, but that runs into a different problem: if I leave the 
implementation empty, then legitimate external calls of 
`fireValueChangedEvent` would become no-ops.

So, I can't change the implementation because then it doesn't do anymore 
what external parties expect, and I can't **not** call it because then 
overriders wouldn't be informed of the change.

The reason this is bothering me is because I see a way to optimize 
memory use for all properties that have a change listener attached, but 
I can't make the change because the Base classes have exposed some 
unfortunate internals.  The optimization is simple; a property has its 
value, but so does ExpressionHelper, it has a copy -- they both have the 
"current" value of the property. It would be trivially easy to supply 
the ExpressionHelper with the old value by saving this value off just 
before changing the property's value, and then supplying it when calling 
`ExpressionHelper#fireValueChangedEvent`... except for this one little 
snag where I'm forced to call `ObjectPropertyBase#fireValueChangedEvent` 
of which I can't change the implementation...

Unfortunately, I don't think there is a way to solve this, so we're 
stuck with having to store the current value of a property in two 
places.  In theory, the `fireValueChangedEvent` method could be made 
final, and any code that overrides it could override `invalidated` 
instead.  In that case, internal calls could go via a different route 
allowing for supplying an old value when its value was set directly, 
while external callers can still use the existing method (which will use 
the current value as its old value, and preferably, also avoids calling 
invalidation listeners when not needed).

--John