The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
SwiftObservables v.1.0.0
2 years ago
This release addresses the strong reference cycle in Binding and adds new functionality to help manage observer closure memory:
1. Added `isObsolete` property to `Observation`.
Set this to `true` to mark an `Observation` and its associated closure for later removal.
2. Added API `cleanse()`
This will purge all entries marked obsolete from an observed property's closure array.
3. All existing APIs (`observe()`, `remove()`, `bind()`, `unbind()`) automatically purge (or replace) entries marked obsolete.
4. Binding is now a weak relationship that can be cleanly severed by freeing one side, even if `unbind()` is never called.
The readme fully describes the use of the new functionality, but in summary:
To mark an observation obsolete, set the `isObsolete` property to `true`:
var ob = $x.observe(.did, using: someClosure)
ob.isObsolete = true
Once this is done, the observation is automatically set to the `.disabled` state so the closure will not be called again:
if (!ob.isEnabled) {
print("It is automatically shut off.") // this will print
}
Once an observation is marked obsolete it cannot be reversed:
ob.isObsolete = false // this is ignored
if (ob.isObsolete) {
print("It can't be undone!") // this will print
}
Likewise, the `kind` property becomes unchangeable for an obsolete closure:
ob.kind = .will // this is ignored now
if (ob.kind == .will) {
print("Sorry, you'll never see this message.") // this never prints
}
Obsolete closures are not immediately released, but will be purged (or replaced) during any future call to the `@Observable` APIs for that property. Since there is no guarantee this may ever occur, you can call `cleanse()` to force it to happen.
$x.cleanse() // any obsoleted closures have now been removed for this object
`cleanse()` is intended to give code controlling the observed object a way to periodically flush out any obsolete closures associated with it (effectively honoring or helping the observer side manage their memory). Since all of `@Observable` calls require access to the observed object it may not always be practical or desirable for an observer to call `remove()`. For instance, if an observer is watching the observed across scopes and no longer has access to it, marking the observation as obsolete tells the system to shut it down and release it prior to the end-of-life of the observed property. This means that observers looking to manage their closure memory don't need to artificially maintain references to the observed object just to release themselves from it.
Note that observing itself is always a weak relationship for the observed object, so observed properties can be released at any time. Observers are the only ones in this implementation that need to be concerned with memory capture -- and then only if they do not wish to be tied to the lifecycle of the observed object, which would release them automatically when it goes out of scope. This new functionality is only to facilitate additional flexibility for how observers manage their lifecycles and is not necessary for many observer-observed relationships.
A future enhancement may introduce a mechanism to globally release all obsolete closures immediately for all observables in memory, to further simplify cases where `remove()` was desired, but impractical.
SwiftObservables v0.9
2 years ago
This release publishes Observer and Binding functionality as a Swift package using Swift property wrappers, as documented in the Readme. This includes the following functionality:
1. Declaration of `@Observable` to attach automatic didSet/willSet functions to any property to trigger any number of observer closures.
2. Four observation states: `.did`, `.will`, `.all`, and .`disabled`
3. A common closure format for both `.did` and `.will` observations.
4. Observation APIs via the projected value (the `$` syntax): `observe` and `remove`
5. Binding APIs via the projected value: `bind` and `unbind`
6. Observation and binding simultaneously permitted on the same objects.
Note this code is considered pre-release mainly due to what is reported in Issue #1 and Issue #2, namely that a strong reference is created for the *observer* side of the observer-observed relationship, which creates a strong reference cycle in the case of binding. While the `remove` and `unbind` calls fix this, the production ready version of this code shouldn't require them explicitly. This issue will be addressed in v1.0.