[swift-evolution] [swift-evolution-announce] [Review] SE-0030 Property Behaviors
brent at architechies.com
Wed Feb 10 17:53:01 CST 2016
As for the proposal itself:
> • What is your evaluation of the proposal?
+1 with no changes suggested.
I do, however, have one caveat: this proposal is a good core for property behaviors, but alone, I don't think it carries its own weight. It will need at least a couple of the items in "Future Directions" section before it's really worth having. If we find we're not able to get those things proposed and accepted, we may want to reconsider whether we should add the feature at all.
Overall, though, I'm eagerly anticipating this feature.
> • Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Special behavior tied to properties is one of the largest sources of boilerplate in Swift, and allowing that boilerplate to be factored out is an extremely welcome step. Ever since the discussions about behaviors first started, I've been keeping an eye out for places I would use them if they were available, and I've spotted many such cases in my code.
> • Does this proposal fit well with the feel and direction of Swift?
Yes. Eventually, this proposal should allow us to rework many ad-hoc features of Swift properties into standard library features. This approach is very, very Swifty.
> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I've used metaprogramming in Ruby and Objective-C to do broadly similar factoring in a different way, by generating accessors at runtime based on pseudo-declarative code. The behaviors approach is less flexible, because it has to be extended for each capability we want to add, but it's also *far* easier to use correctly.
I also have experience with the Perl 6 approach (I haven't actually used the final Perl 6, but I was active in its design process, and actually wrote a proof-of-concept CMS for Pugs as a Summer of Code project). Perl 6 does this quite differently; essentially, it makes the variable an object of its own, separate from the value stored in it, and allows you to apply roles (traits/mixins) to the variable in order to customize its behavior. This is a very, very powerful approach, but it would most likely introduce more overhead than is appropriate for Swift, which aspires to be a systems language.
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I participated quite heavily in the preliminary discussions and submitted detailed critiques at that time; it's probably safe to say that I have not suggested any changes because my suggestions have already been discussed and incorporated where appropriate. I've also been keeping an eye out in my Swift codebases for places where I would have used behaviors if they were available.
For this review specifically, I re-read the proposal from top to bottom.
More information about the swift-evolution