[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions

[David Hart]

>> (2) in many cases, it doesn't matter anyway (like maybe that tableView is an argument and not your property, but still the same object);

That’s actually a very good example.

Most of the time, your UIViewController or UITableViewController’s self.tableView is the same object as UITableViewDelegate’s tableView method argument. But I’ve had several cases in my app development career where that UIViewController was also used for updating a different tableView (for example a tableView used for search) which uses the same delegate, but where it is paramount to use the argument variable and not the instance variable.

I’ve actually had a bug due to that where code review was very quick because cellForRowAtIndexPath was using self.tableView instead of tableView and we saw it straight away.

>> (3) the code is fairly verbose as it is, and adding any extra syntactic elements obscures its intention.

Like many before, I think this is a question of taste. In our team, we don’t find it particularly verbose and we actually think it clarifies intention.

>> And, perhaps more importantly, Xcode uses a different color to highlight property names. There's no need for further textual differentiation there.

Like already said early in the discussion: some code review tools don’t show good enough color syntaxing, and even when in Xcode, I (and several others) are colourblind enough not to see the difference in those colours.

David.

> On 14 Dec 2015, at 22:59, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Oh, one more point: in the UI code I mentioned, I often switch between a property and a variable (e.g. turning a locally-declared label into a field if I find myself needing to update it elsewhere), and it would be very irksome to have to go and update all the references.
> 
> Also, how often do you actually encounter a bug caused by confusion between properties and variables? I had maybe two property/argument collisions and one property/local var collision that I had to debug in my 1.5 years of swifting. Compared to that, writing "self." would be an everyday annoyance.
> 
> A.
> 
> 
>> On Dec 15, 2015, at 3:54 AM, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> We are fortunate because the Python mailing list debated this exact
>>> issue in 2006 (albeit, in the reverse direction). I’ll quote from
>>> https://www.python.org/dev/peps/pep-3099/ (“Things that will Not
>>> Change in Python 3000”):
>>> 
>>>> Having self be explicit is a good thing . It makes the code clear by removing ambiguity about how a variable resolves. It also makes the difference between functions and methods small.
>> 
>> Theoretically, if we were debating this on principle, I would agree with explicit self references.
>> 
>> However, I talk from experience using the relevant Apple frameworks writing dozens of apps. The UI code, which is more than a half of a typical app's code, consists of lines upon lines of simple object setup and manipulation, where (1) it is absolutely clear which names are properties and which are variables; (2) in many cases, it doesn't matter anyway (like maybe that tableView is an argument and not your property, but still the same object); (3) the code is fairly verbose as it is, and adding any extra syntactic elements obscures its intention.
>> 
>> And, perhaps more importantly, Xcode uses a different color to highlight property names. There's no need for further textual differentiation there.
>> 
>> A.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution