New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modeling private(set) var
behavior using properties
#19
Comments
You may wrap it a public version of it as |
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 @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 in RAC:
and then
Was there a large amount of rationale around PropertyProtocol forcing classes now? I see the comment at the top of the file:
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? |
Sure. But I thought the need of boilerplate should have been reduced by the introduction of property composition, hmm?
Nothing is resolved IMO. The given 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
@NachoSoto might have a few words.
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. |
Hi, I'm trying to figure out the best way to model behavior similar to
when a function has side effects changing the value of the
property
.The main goal of this exercise is to expose a readonly property that is modified from within the object using ReactiveSwift. My current setup looks like this:
but that also allows changing property value from the outside of the object, e.g.
object.property.value = newUnexpectedValue()
which is what I want to avoid.Thank you!
The text was updated successfully, but these errors were encountered: