Community
Participate
Working Groups
Currently an observable can be constructed from a property and the source object will not be consulted or even verified to be the correct type until listeners are registered or an accessor / mutator is called on the observable. Ideally properties should assert that source objects are the correct type (or null) before constructing observables.
Created attachment 128961 [details] Patch Boris, there is a test that throws an exception with this patch (testGetValueThrowsExceptionThrownByBean). I'm using property.getValue() as a sniff test at runtime to ensure that the property source is the right type for the property. I'm not sure if we should revise the test or take a different approach. I was in the middle of revising properties to override observe(Realm, Object) and cast the Object to the expected type before calling the super implementation. However I had to do this on every single property class and doing the test once in the observable seemed a better approach. Thoughts?
Created attachment 128962 [details] mylyn/context/zip
Thinking about this more, I think that property.getValue() is not a good test since for these two conditions: A) object is the wrong type B) property getter throws exception A implies B but B does not imply A. With B you could be rethrowing an exception thrown from the property source itself. I guess this will have to be done the ugly way.
Created attachment 128999 [details] Patch Added methods to Simple<Value|List|Set|Map>Property: /** * Returns the type of source object this property may be used with. * * @return the type of source object this property may be used with. */ public Object getSourceType(); /** * Throws an exception if the source object is not the correct type. */ protected void checkSourceType(Object source);
Created attachment 129000 [details] mylyn/context/zip
Created attachment 129001 [details] Patch updated javadoc comments
Created attachment 129002 [details] mylyn/context/zip
This patch introduces new API so it has to wait until 3.6
Changing Version tag to something more believable. Note that this is not a statement about when the enhancement request will be addressed (the Target Milestone field is used for that); the Version tag should be set to the version of Eclipse you were using when you saw the need for the enhancement.
Removed from 3.6. Owners can re-assess. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
