[swift-evolution] [Proposal] Property behaviors

[Michel Fortin]

Le 19 janv. 2016 à 21:38, John McCall via swift-evolution <swift-evolution at swift.org> a écrit :

> One of my worries about this proposal in general is that you’ve listed out half-a-dozen different uses and every single one seems to require a new twist on the core semantics.

That's my general feeling too about this proposal. I just didn't know how to express what you said above.

To me this proposal feels like it's is about trying to find a solution to multiple problems at once. A new problem arise that looks like it could be solved by a behaviour, so the behaviour feature expands to accommodate it. It looks like the wrong approach to me. 

The correct approach in my opinion would be to try to make various parts of this proposal standalone, and allow them to combine when it makes sense. For instance, if you wanted to define a standalone feature for defining custom accessors that can be used everywhere, you wouldn't come with something that requires a behaviour annotation at the variable declaration. You'll come with something simpler that might looks like this:

custom_acccessor willSet<T>(newValue: T) { // define a custom accessor...
	set { // ... by redefining the setter...
		willSet(newValue) // ...inserting a call to the accessor here...
		currentValue = newValue // ...before calling the underlying setter
	}
}
custom_acccessor didSet<T>(oldValue: T) {
	set {
		let oldValue = currentValue
		currentValue = newValue
		didSet(oldValue)
	}
}
custom_acccessor willChange<T>(newValue: T) {
	willSet {
		if currentValue != newValue {
			willChange(newValue)
		}
	}
}

Then at the declaration point you just directly use the globally accessible accessor:

	var myvar: Int {
		willChange { print("will change to \(newValue)") }
	}

This fulfills at least one of the use cases. Can't we do the same treatment to each proposed use cases and see if there are other parts that can stand on their own?

-- 
Michel Fortin
https://michelf.ca