Modeling `private(set) var` behavior using properties about reactiveswift

[ikesyo]

Property type would be what you want:

class Object {
  private let _property: MutableProperty<Type>
  func sideEffects() {
    _property.value = newValue()
  }

  // Returns a read-only property that wraps an underlying property.
  var property: Property<Type> {
    return Property(_property)
  }
}

[andersio]

You may wrap it a public version of it as Property.

[zats]

Oh, thanks a lot @andersio and @ikesyo! Sorry for the beginner's questions 🙂

[robertjpayne]

@andersio @ikesyo Is there any room for discussion on this? This is one area of ReactiveSwift that really is unfortunate and ends up bloating code and requiring a large amount of boilerplate.

I'd argue most properties are going to be read-only by default outside of the owner.

This could be solved pretty easily using a struct type for Property rather than a class type, I did this previously in RAC but can no longer do it with ReactiveSwift because PropertyProtocol now forces classes.

in RAC:

struct Property<Value>: PropertyType {
    
    var value: Value {
        get {
            return self.mutableProperty.value
        }
        set {
            self.mutableProperty.value = newValue
        }
    }
    
    private let mutableProperty: MutableProperty<Value>
    
    init(_ value: Value) {
        self.mutableProperty = MutableProperty(value)
    }
    
    var producer: SignalProducer<Value, NoError> {
        return self.mutableProperty.producer
    }
    
    var signal: Signal<Value, NoError> {
        return self.mutableProperty.signal
    }
    
}

and then

private(set) var name = Property<String>("Robert")

Was there a large amount of rationale around PropertyProtocol forcing classes now? I see the comment at the top of the file:

Only classes can conform to this protocol, because having a signal for changes over time implies the origin must have a unique identity.

To me this is enforcing an ideological barrier, there's an initialiser that takes a signal and thus you've already created API that breaks this theory that the source is unique?

[andersio]

Is there any room for discussion on this? This is one area of ReactiveSwift that really is unfortunate and ends up bloating code and requiring a large amount of boilerplate.

Sure. But I thought the need of boilerplate should have been reduced by the introduction of property composition, hmm?

This could be solved pretty easily using a struct type for Property rather than a class type, I did this previously in RAC but can no longer do it with ReactiveSwift because PropertyProtocol now forces classes.

Nothing is resolved IMO. The given Property, wrapping a MutableProperty, does not really have value semantics. What should happen when you reference it by copying, while the encoded type is telling "I am a value type"?

Edit: Of course alternatively, we may do CoW, so that each uniquely referenced copy has its own signal. But the problem is that CoW does not have a concept of ownership. So when a supposed owner of the property writes to a non-uniquely-referenced property that it supposedly own, it creates another copy instead, abandoning all its observers in the previous copy.

Edit 2: All I can say is, while being able to model them using access control modifiers is great, we do not have the right primitives in the language to make it reliable (yet), while satisfying all the reasonable constraints that should be followed.

Edit 3: Not sure if you have already known, but you may use lazy to define the public variant of a mutable property of yours.

private(set) lazy var name: Property<String> = Property(self._name)
private let _name = MutableProperty<String>("")

@NachoSoto might have a few words.

Only classes can conform to this protocol, because having a signal for changes over time implies the origin must have a unique identity.

To me this is enforcing an ideological barrier, there's an initialiser that takes a signal and thus you've already created API that breaks this theory that the source is unique.

A property observing a signal or a producer is still unique, because the (produced) signal and the observation made to it is unique. It is not that it never has identity too, just that it was hidden in RAC 4.0, and it wasn't a huge problem since it is read-only after all.