I have the same feeling. Syntax highlighting is not enough to make things clear and even with it we are sometimes confused. We read swift code on GitHub, which doesn't have highlighting. Sometimes we do so in plain text. It looks like the only way to detect iVars is to open our Swift code is to open it in Xcode. So Swift is outsourcing iVar readability to Xcode, when it should be a language feature.
Given this, some teams use underscores for their iVars which is very unfortunate. Myself, I use self whenever possible to be explicit. I'd like the language to force us to be clear.
I would also like to point out that colours are a very unsafe mechanism of communicating programmer intent.
···
Message: 1
Date: Sat, 5 Dec 2015 10:35:08 +0100
From: David Hart <david@hartbit.com>
To: Tyler Cloutier <cloutiertyler@aol.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] Proposal: Re-instate mandatory self for
accessing instance properties and functions
Message-ID: <F9CA7C02-6596-4C36-A867-3613DE3D7DB7@hartbit.com>
Content-Type: text/plain; charset="utf-8"
As I said previously, same for me. But even if that weren't the case; I find it difficult to defend the readability of a language's feature uniquely by an editor's syntax highlighting.
The proposal here had the same objectives (but is more elegant) to what created conventions like Hungarian notation where m_ prefixes member variables.
Sent from my iPhone
On 05 Dec 2015, at 08:49, Tyler Cloutier <cloutiertyler@aol.com> wrote:
I'm not sure how many Swift users this effects, but I'm colorblind and I really struggle with the local vs properties syntax coloring.
Tyler
On Dec 4, 2015, at 3:37 PM, Kevin Ballard <kevin@sb.org> wrote:
Do you use Xcode to edit Swift? Xcode gives a color to properties/methods and doesn't color local variables/arguments. Is that not sufficient to distinguish this? In my experience the color is actually better than seeing the explicit `self.` because the color can be recognized faster than reading a word, and is visible in a high-level "squint" view of the function.
If you're using another editor, well, my best suggestion there is to look into what it would take to integrate SourceKit functionality into that editor for more intelligent coloring :)
-Kevin
On Fri, Dec 4, 2015, at 03:29 PM, Colin Cornaby wrote:
+1
I've had a lot of weird things happen that I've traced to mistakes in properties having the same name as function arguments. I've hardly ever had this issue in modern Obj-C.
I'm a little more ok with functions not needing self as it's less likely for those to shadow something like an argument, but I guess the consistency would be nice too.
On Dec 04, 2015, at 01:20 PM, David Hart <david@hartbit.com> wrote:
I don't understand the reasoning behind removing the need to access instance properties and functions using self. Swift has always seemed to prefer readability to brevity and the feature makes the distinction between local and instance variables/functions crystal clear. Any good reason I shouldn't go on with the proposition?
Just as example, my proposition makes the following piece of code illegal:
Keep it an option (-fself-ivar-access and -Wself-ivar-access) only please, or you break compatibility.
···
On Dec 5, 2015, at 19:34, Dan <robear18@gmail.com> wrote:
I have the same feeling. Syntax highlighting is not enough to make things clear and even with it we are sometimes confused. We read swift code on GitHub, which doesn't have highlighting. Sometimes we do so in plain text. It looks like the only way to detect iVars is to open our Swift code is to open it in Xcode. So Swift is outsourcing iVar readability to Xcode, when it should be a language feature.
Given this, some teams use underscores for their iVars which is very unfortunate. Myself, I use self whenever possible to be explicit. I'd like the language to force us to be clear.
I would also like to point out that colours are a very unsafe mechanism of communicating programmer intent.
Message: 1
Date: Sat, 5 Dec 2015 10:35:08 +0100
From: David Hart <david@hartbit.com>
To: Tyler Cloutier <cloutiertyler@aol.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] Proposal: Re-instate mandatory self for
accessing instance properties and functions
Message-ID: <F9CA7C02-6596-4C36-A867-3613DE3D7DB7@hartbit.com>
Content-Type: text/plain; charset="utf-8"
As I said previously, same for me. But even if that weren't the case; I find it difficult to defend the readability of a language's feature uniquely by an editor's syntax highlighting.
The proposal here had the same objectives (but is more elegant) to what created conventions like Hungarian notation where m_ prefixes member variables.
Sent from my iPhone
On 05 Dec 2015, at 08:49, Tyler Cloutier <cloutiertyler@aol.com> wrote:
I'm not sure how many Swift users this effects, but I'm colorblind and I really struggle with the local vs properties syntax coloring.
Tyler
On Dec 4, 2015, at 3:37 PM, Kevin Ballard <kevin@sb.org> wrote:
Do you use Xcode to edit Swift? Xcode gives a color to properties/methods and doesn't color local variables/arguments. Is that not sufficient to distinguish this? In my experience the color is actually better than seeing the explicit `self.` because the color can be recognized faster than reading a word, and is visible in a high-level "squint" view of the function.
If you're using another editor, well, my best suggestion there is to look into what it would take to integrate SourceKit functionality into that editor for more intelligent coloring :)
-Kevin
On Fri, Dec 4, 2015, at 03:29 PM, Colin Cornaby wrote:
+1
I've had a lot of weird things happen that I've traced to mistakes in properties having the same name as function arguments. I've hardly ever had this issue in modern Obj-C.
I'm a little more ok with functions not needing self as it's less likely for those to shadow something like an argument, but I guess the consistency would be nice too.
On Dec 04, 2015, at 01:20 PM, David Hart <david@hartbit.com> wrote:
I don't understand the reasoning behind removing the need to access instance properties and functions using self. Swift has always seemed to prefer readability to brevity and the feature makes the distinction between local and instance variables/functions crystal clear. Any good reason I shouldn't go on with the proposition?
Just as example, my proposition makes the following piece of code illegal:
Perhaps it could be a warning option. But I don’t think that breaking compatibility is an argument: many changes in Swift 3 continue to break source compatibility. Swift is not yet source stable, and still one year from being ABI stable.
···
On 05 Dec 2015, at 14:43, Maxthon Chan <xcvista@me.com> wrote:
Keep it an option (-fself-ivar-access and -Wself-ivar-access) only please, or you break compatibility.
On Dec 5, 2015, at 19:34, Dan <robear18@gmail.com> wrote:
I have the same feeling. Syntax highlighting is not enough to make things clear and even with it we are sometimes confused. We read swift code on GitHub, which doesn't have highlighting. Sometimes we do so in plain text. It looks like the only way to detect iVars is to open our Swift code is to open it in Xcode. So Swift is outsourcing iVar readability to Xcode, when it should be a language feature.
Given this, some teams use underscores for their iVars which is very unfortunate. Myself, I use self whenever possible to be explicit. I'd like the language to force us to be clear.
I would also like to point out that colours are a very unsafe mechanism of communicating programmer intent.
Message: 1
Date: Sat, 5 Dec 2015 10:35:08 +0100
From: David Hart <david@hartbit.com>
To: Tyler Cloutier <cloutiertyler@aol.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] Proposal: Re-instate mandatory self for
accessing instance properties and functions
Message-ID: <F9CA7C02-6596-4C36-A867-3613DE3D7DB7@hartbit.com>
Content-Type: text/plain; charset="utf-8"
As I said previously, same for me. But even if that weren't the case; I find it difficult to defend the readability of a language's feature uniquely by an editor's syntax highlighting.
The proposal here had the same objectives (but is more elegant) to what created conventions like Hungarian notation where m_ prefixes member variables.
Sent from my iPhone
On 05 Dec 2015, at 08:49, Tyler Cloutier <cloutiertyler@aol.com> wrote:
I'm not sure how many Swift users this effects, but I'm colorblind and I really struggle with the local vs properties syntax coloring.
Tyler
On Dec 4, 2015, at 3:37 PM, Kevin Ballard <kevin@sb.org> wrote:
Do you use Xcode to edit Swift? Xcode gives a color to properties/methods and doesn't color local variables/arguments. Is that not sufficient to distinguish this? In my experience the color is actually better than seeing the explicit `self.` because the color can be recognized faster than reading a word, and is visible in a high-level "squint" view of the function.
If you're using another editor, well, my best suggestion there is to look into what it would take to integrate SourceKit functionality into that editor for more intelligent coloring :)
-Kevin
On Fri, Dec 4, 2015, at 03:29 PM, Colin Cornaby wrote:
+1
I've had a lot of weird things happen that I've traced to mistakes in properties having the same name as function arguments. I've hardly ever had this issue in modern Obj-C.
I'm a little more ok with functions not needing self as it's less likely for those to shadow something like an argument, but I guess the consistency would be nice too.
On Dec 04, 2015, at 01:20 PM, David Hart <david@hartbit.com> wrote:
I don't understand the reasoning behind removing the need to access instance properties and functions using self. Swift has always seemed to prefer readability to brevity and the feature makes the distinction between local and instance variables/functions crystal clear. Any good reason I shouldn't go on with the proposition?
Just as example, my proposition makes the following piece of code illegal: