how to handle gotchas related to Property setDeferred

[pixelzoom]

Over in #277, I encountered Property setDeferred for the first time. This feature seems to have gotchas that are not at all guarded.

For example, after a set, you may still get the old value:

> var x = new phet.axon.Property( 'foo' )
undefined
> x.setDeferred( true )
null
> x.value = 'bar'
"bar"
> x.value
"foo"

Should get() fail an assertion if it's called while this.isDeferred === true?

Are there other gotchas?

[zepumph]

Are there other gotchas?

Looking through Property functions, perhaps reset also?

This is a pretty serious bug; one that I am unsure how to solve easily but which is easy to demonstrate.

1. Add this line to the top of Properyt.get():
   assert && assert( !this.isDeferred, 'value may be stale if this Property is deferred' );
2. Add a debugger; to assert.js
3. Fuzz the state wrapper for Charges And Fields.

In the general case, calling get on a Property that is currently deferred could occur anywhere in the code, and this is only exposed by the state wrapper. I'm going to raise priority for the PhET-iO team to investigate.

[pixelzoom]

resetdoes seem like a problem. If reset is called while this.isDeferred === true, then the reset is deferred.

I understand the motivation for this "deferred" feature. But it seems like something that should be avoided. And it's not robustly instrumented or adequately tested - only 1 unit test!

[samreid]

Should get() fail an assertion if it's called while this.isDeferred === true?

I don't think so--that would break its interface. You should be able to get a Property value at any time. When a property is deferred, you should still be able to read the old value. This behavior is also tested in the unit test:

  const property = new Property( 0 );
  //...
  property.setDeferred( true );
  property.value = 1;
  property.value = 2;
  assert.equal( property.value, 0, 'should have original value' );

Reset also makes sense to me. Resetting is equivalent to setting the original value. So it should behave the same as any defer.

But it seems like something that should be avoided.

Agreed, we have been using it sparingly. Particularly because it is not re-entrant.

And it's not robustly instrumented or adequately tested - only 1 unit test!

Yes, there is only 1 test, but 7 assertions are tested in it. What else do you recommend to test?

[pixelzoom]

You should be able to get a Property value at any time. When a property is deferred, you should still be able to read the old value.

I disagree. What is the use case for reading a Property's value while it's in a deferred state? Imo this encourages a certain type of code that should be avoided.

Reset also makes sense to me. Resetting is equivalent to setting the original value. So it should behave the same as any defer.

Again, I disagree. What is the use case?

And there are other things that don't seem to have been considered (or maybe just not documented?):

• notifyListenersStatic can be called while deferred. Why?
• Listeners can be added/remove while deferred? Why?
• After dispose, setDeferred(false) is forbidden, but get is allowed. Why?

Agreed, we have been using it sparingly. Particularly because it is not re-entrant.

If we're going to use it sparingly, what is the purpose of allowing anything other than set(value) and setDeferred(false) while deferred?

Yes, there is only 1 test, but 7 assertions are tested in it. What else do you recommend to test?

Recommended tests:

• reset while deferred
• dispose while deferred
• DerivedProperty tests where the DerivedProperty and/or dependencies are deferred

Robustness:

• document the "deferred" behavior for all relevant methods
• review which methods should be allowed while deferred
• review what is allowed after dispose has been called