[swift-evolution] [Review] SE-0009 - Require self for accessing instance members
jeremy.j.pereira at googlemail.com
Thu Dec 17 04:50:45 CST 2015
-1 to this proposal
• What is your evaluation of the proposal?
I think the proposal addresses a minor problem in the wrong way. I think it seeks to solve the issue of shadowing variables by forcing a particular coding style on programmers.
There is at least one error of fact in the proposal "as is intrinsically the case in Objective-C”. This is not the case with Objective-C instance variables where “self->ivar” is not mandatory.
I also disagree with the assertion that it is "more readable at the point of use”. I think that is entirely subjective and I and several other participants have disagreed with this assertion.
I agree that it is “more consistent than only requiring self in closure contexts”. However, the use of optional self in some situations and not others actually aids readability. The often cited instance is in closures to remind the programmer that self is captured.
It may be fractionally less confusing from a learning point of view, but I think a programmer that cannot grasp this is going to struggle with many of the more complex language features anyway. Other languages adopt the same pattern as Swift (e.g. Java, C++, Objective-C for instance variables) and learners in these languages do not seem to have problems in this respect.
I think this proposal will lead to anti-patterns like the following because people will want to get rid of all the “unsightly” selfs:
var x: Int
var y: Int
var x = self.x
var y = self.y
// Do complicated stuff with the local variables
The above could be, in itself, a source of bugs e.g. changing the local x and y and forgetting to write them back to the properties.
Finally, the "Alternatives Considered" section does not consider any alternatives other than status quo. There is at least one alternative to resolve the issue the proposal seeks to address.
I’m also concerned that the “Community Responses” section includes only the positive feedback. There was quite a lot of negative feedback on the list too. Where is it?
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes. However, the proposed solution is wrong. I would suggest a compiler warning for when a property or global is shadowed by a local variable would be sufficient.
• Does this proposal fit well with the feel and direction of Swift?
No. As a rule, the drive with Swift is to remove unnecessary boilerplate. This is adding it in.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I have done a lot of reading of the thread on the swift-evolution list. Other than that, only the time to write this response.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution