Changes to the DynamicProperty semantics.

[andersio]

Make it more Property alike - a lens to a key path of an NSObject without its own lifetime.

1. A DynamicProperty retains its lensing object.

2. The producer and signal respects the lifetime of the object being lensed.

3. Bindings targeting DynamicProperty ties directly to the object being lensed.

4. DynamicProperty is now leak safe - reusing instances is no longer necessary.

   For example:

   DynamicProperty<Int>(object: controller,
                        keyPath: #keyPath(Controller.value)) <~ aProducer
   

   would still be valid even if the DynamicProperty has gone out of scope. It would last until controller deinitializes, or aProducer terminates.

[NachoSoto]

A DynamicProperty retains its lensing object.

👎 I don't think this is the way to go. A DynamicProperty represents the values over time for a given object's property, which does not mean that it //owns// the object. In fact, it means the complete opposite. This is equivalent to how NSNotificationCenter does not retain the object (#2859, for example).

The producer and signal respects the lifetime of the object being lensed.

Now, //these// semantics I think are correct. But the previous point kind of breaks this because there would be one extra artificial owner.

[NachoSoto]

Why Optional? representation can always be an optional (since it's Any).

[andersio]

If you pass an optional to Any, it would be bridged to an opaque box (SwiftValue) regardless of being nil or not. The KVC interface in fact anticipates Any?.

The way DynamicProperty is initialised also restricted the implementation options. Since optionals are neither bridgeable nor conforming to AnyObject, new initializers have to be tailored for optionals with the OptionalProtocol constraints. Unless we assume all key paths are nullable & requires manual nil skipping.

[andersio]

It might be confusing since DynamicProperty was (IIRC) originally introduced to serve as a binding mediator, and hence wasn't "owning" the object but in another way round to avoid reference cycles. But with the introduction of BindingTarget, it is now possible to establish bindings without such mediator. So I proposed to reposition it as a "lens".

It creates a reduced view (lens) to the NSObject, which concerns only a certain key path. In this sense, you are still accessing the object directly, i.e. conceptually the same as let value = { object.property }.

However, all other stuff (producer/signal/lifetime/binding) is decoupled and instead derived directly from the underlying object. This aligns with our property composition and signal lifetime semantics.

For example, if you retain propertyA.map { $0.name } as name, propertyA is retained by name even if you throw your last reference to it away.

Now treat propertyA as the NSObject, and name as the DynamicProperty. :)

It also eliminates potential leaks due to misuse, since at this moment every instance of DynamicProperty is automatically retained by the observed object upon creation.

This is actually similar to Groff's idea of "property lenses" for property reflection, say a () -> inout U, where a full property interface (that captures the object/struct) can be obtained and passed around.

[mdiep]

I agree with @NachoSoto on this.

I think the weak semantics are more common here; although you'll certainly want strong on occasion. But it's also easier to make the semantics stronger than to make them weaker when you want the other behavior.

I definitely get what you're saying about the lens behavior. But if we want to support those semantics, they need to be in addition to the current semantics—not as a replacement.

[mdiep]

I don't think we should give DynamicProperty lens semantics. I don't think that's the role it plays. It's meant to make values reactive/observable. It's similar to a lens, but I think going down that route is a mistake that distracts from the core value of RAC.

Going back to your original example:

DynamicProperty<Int>(object: controller,
                     keyPath: #keyPath(Controller.value)) <~ aProducer

I don't think that provides much value. If the DynamicProperty isn't kept around to reuse or observe, then there's no point in using a property. You can just as easily use startWithValues.

[andersio]

Yeah, and that lens-ish part has been removed. What's left here is the removal of the strong reference, so that DynamicProperty needn't be deliberately uniqued.

[mdiep]

Yeah, and I just don't think those are the right semantics for DynamicProperty. 😞

[andersio]

I don't think the semantics have changed per the state of PR, other than lifting the need of uniquing. If we agree that the main rationale of DynamicProperty being bound to the underlying object is to allow the bindings to propagate values, the PR just does the same in an alternative way.

If the need of uniquing is a deliberate feature, I would argue that the initializer should hide behind something that does the uniquing, instead of the slippery ground we have now.