[swift-evolution] [Review] SE-0030 Property Behaviors

[Myles Schultz]

+1 for this review. I feel the same in regard to the clunky interface. It feels redundant and an extension instead of part of the property. One could argue that that is what was I ended, but...

On Feb 14, 2016, at 12:16 PM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> There are many disparate problems this proposal is trying to address.
> 
> Some of the problems illustrated in the proposal would benefit from it, but not all. In some cases, such as the `observed` behavior, it makes things worse because your observer functions have to be tied to a behavior attached to the variable.
> 
This is what I have been trying to say. One shouldn't have to invoke the behavior to get the behavior. It should be understood from declaration the a given property has a given set of behaviors. 
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Accessing functions inside behaviors such as `resettable` adds two layers of metadata/meta-operations to the property (one is the behavior name, the other is the `reset()` function). I would argue that including `resettable` before calling a `reset()` function is redundant.

Again, what Have been trying to say:  you shouldn't need to say, "property, I'm going to use this behavior I gave you. Behavior please do ____". It's clunky and makes you feel like your now dealing with the property, but a third party. It's like HIPPA when you have a patient with dementia--"I'm going to discuss some things with your family unless you don't have any other questions. Family ... " (forgive me, I'm a physician, so this analogy makes sense to me). 

> It is also against the principles of separation between the interface and the implementation since you might want to define `reset()` in your own way for some variables, which would entail the creation of a separate behavior with a different name, which would change the way you make your `reset()` call. To me, the way you can call behavior functions seems rather heavyweight and inflexible.

This was pointed out to me that if the property and the behavior have a function with the same name, the problem of which to choose begins. I agree that this should be a non-issue. This leaves too much of the language implementation exposed to user of the language. To me the ideal would be to state that a property has some behavior and then everything "just works" from there with having to micromanage the behavior. We don't tell ARC what to do. Maybe that's a poor example, but it seems like it is on the same level. 
> 
> Swift currently lets you add `willSet` and `didSet` observers without having to opt-in through some special syntax. Requiring that a behavior be added, such as `observed` before being able to use these or other custom kinds of observers seems like a step in the wrong direction to me.

I really didn't like this part of the proposal, but you take the good with the bad. I like that property over are available from the get go. You don't have to manually say, "property, I grant you the ability to observe".

> 
> -- 
> Michel Fortin
> https://michelf.ca
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution