This is related to #28. Also, it's potentially a nice way for us to remove a fork that may not be providing much benefit.
Benefits to making these static:
no chance of naming collision for instance level properties
one less fork in our code
information can be used in static analysis since it doesn't depend on an instance
Downsides to making these static:
a bit more restrictive
observer callback may fell a bit less ergonomic since we'll change the call signature
For computed... There's not too much argument here, there should be no need to provide a target. Forcing these methods to be static will also help with potential, future memoization of computations.
For observer... We want to support access to the target still, so we would need to change the signature to be myCallback(target, value, oldValue)--or something like that.
@klebba , we discussed this at one point as a "funny, terrible idea". I still think the pros outweigh the cons here, but we should have more discussion before implementing.
This is related to #28. Also, it's potentially a nice way for us to remove a fork that may not be providing much benefit.
Benefits to making these static:
Downsides to making these static:
For
computed
... There's not too much argument here, there should be no need to provide atarget
. Forcing these methods to bestatic
will also help with potential, future memoization of computations.For
observer
... We want to support access to thetarget
still, so we would need to change the signature to bemyCallback(target, value, oldValue)
--or something like that.