Proposal: 0009 Require self for accessing instance members


(Michael Brown) #1

I couldn't agree more on all points. I strongly object to this proposal. Requiring self makes code unnecessarily verbose and is one of the things I least liked about Objective-C compared to other languages (e.g. C#, Python, Java) where the use of self/this is optional. It is only only actually necessary when resolving ambiguity with local variables, in the few situations where such ambiguity exists (initialisers mostly).

The use of self for accessing instance members is a question of coding style, and should not be made mandatory by the language. If the supporters of this proposal want to use self everywhere, then they are quite free to do so, but please don't force this on everyone!

Michael.

···

On Tue, Dec 15, 2015 at 21:03 Sune Foldager via swift-evolution <swift-evolution@swift.org> wrote:

Personally, I am against using mandatory self. I have coded a lot of Python, and I find it quite annoying to have to type (and read) “self.” everywhere. It’s a balance, of course:

“self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".

I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.

Also, the “Community Responses” section exclusively lists positive feedback. Is that how it’s supposed to be with the SE process? If not, where are the arguments from people who are -1 on the proposal?

I really hope the review team considers:
- The negative responses on this list as well. Also consider that many Swift developers are not on this list; I doubt it’s representative, either, being dominated by “language interested” developers.
- The rather large amount of changes to existing code required.


(Dan Loewenherz) #2

Correction: self is not optional in Python.

I mentioned this earlier on the thread, but if anyone wants a further, more
“in-depth” reading of the subject, there is plenty of debate out there. For
what seems like time immemorial, there have been lobbies to make self
implicit in Python as well (none have succeeded).

Guido van Rossum wrote a post on this very topic which might be somewhat
relevant. There are reasons specific to Python as to why it can’t remove
self (e.g., it was never implicit), but the post touches on other reasons
relevant to Swift’s situation as well:
http://neopythonic.blogspot.in/2008/10/why-explicit-self-has-to-stay.html

The comments of the post are also pretty illuminating from both sides.

Dan

···

On Thu, Dec 17, 2015 at 11:28 AM, Michael Brown via swift-evolution < swift-evolution@swift.org> wrote:

On Tue, Dec 15, 2015 at 21:03 Sune Foldager via swift-evolution < > swift-evolution@swift.org> wrote:

> Personally, I am against using mandatory self. I have coded a lot of
Python, and I find it quite annoying to have to type (and read) “self.”
everywhere. It’s a balance, of course:
>
> “self.” everywhere means you can see what’s an instance member and
what’s a local variable. That’s generally a good thing. But it also means a
lot of filler text in your code, which makes reading and writing slower.
That’s not so good. It’s a balance, and in this case my experience from C#
(and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of
“this”/“self".
>
> I see that this proposal is going to be reviewed as SE-0009, and I am a
bit concerned that not all arguments are being considered because of the
contents of the proposal text: The only counter argument mentioned in the
proposal has to do with capturing semantics in closures. This is fine, but
why isn’t the counter argument of verbosity being mentioned? This has been
brought up on the list as well.
>
> Also, the “Community Responses” section exclusively lists positive
feedback. Is that how it’s supposed to be with the SE process? If not,
where are the arguments from people who are -1 on the proposal?
>
> I really hope the review team considers:
> - The negative responses on this list as well. Also consider that many
Swift developers are not on this list; I doubt it’s representative, either,
being dominated by “language interested” developers.
> - The rather large amount of changes to existing code required.

I couldn't agree more on all points. I strongly object to this proposal.
Requiring self makes code unnecessarily verbose and is one of the things I
least liked about Objective-C compared to other languages (e.g. C#, Python,
Java) where the use of self/this is optional. It is only only actually
necessary when resolving ambiguity with local variables, in the few
situations where such ambiguity exists (initialisers mostly).


(Michael Brown) #3

Yes. I realized my mistake soon after I hit send. Apologies.

Michael.

···

On 17 Dec 2015, at 17:54, Dan Loewenherz <dan@lionheartsw.com> wrote:

On Thu, Dec 17, 2015 at 11:28 AM, Michael Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Tue, Dec 15, 2015 at 21:03 Sune Foldager via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> “self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".
>
> I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.
>

I couldn't agree more on all points. I strongly object to this proposal. Requiring self makes code unnecessarily verbose and is one of the things I least liked about Objective-C compared to other languages (e.g. C#, Python, Java) where the use of self/this is optional. It is only only actually necessary when resolving ambiguity with local variables, in the few situations where such ambiguity exists (initialisers mostly).

Correction: self is not optional in Python.


(Daniel Hooper) #4

I have mixed feelings about this proposal: I see some value in the problems
it is trying to address, though there are other ways to solve them.

The two problems it tried to address that I consider legitimate:
1. bullet proofing against bugs.
The example in the motivation section is a good one. I can imagine this
happening, though I haven't ever personally experienced it, so how often
does it really happen? Is it often enough to warrant this requirement? The
root cause of that bug is that the instance variable was shadowed by a
local one. Requiring self is one way to ensure local variables don't shadow
instance variables, but the compiler could also just disallow shadowing
instance variables. Details aside, the take away here is that there are
other solutions to this problem.

2. Clarity at the call site.
Syntax highlighting solves this with two caveats: color blindness and
non-colored code, such as diffs in the terminal. Color blindness can be
helped by changing the coloring rules to make it easier to differentiate
ivars. I don't have an answer for situations with no syntax coloring,
though in my own workflow that isn't really an issue. For teams that it is,
they could require use of self, or ivar prefixes ("var _ivar")

So while both problems could be legitimate, there are other ways of
addressing them that don't require the verbosity of "self."

Thought experiment:
"self." has a lot of baggage from obj-c, python, etc, so as an experiment
let's extended this proposal to it's logical conclusion and see how we feel
about it: Global variables and functions have this same shadowing situation
that ivars and instance methods do: an identifier without "self." could be
referencing a local or global variable. Here is the same example from the
proposal, but with a global variable instead of the ivar:

let greeting = "Hi There"

class MyViewController : UIViewController {
    @IBOutlet var button: UIButton!

    func updateButton() {
        // var greeting = "Good morning"
        button.setTitle(greeting, forState: .Normal) // forgot to
comment this line but the compiler does not complain and greeting is
now referencing global greeting by mistake
    }
}

By this proposal's logic we should create a "global." prefix and require it
to access global variables and functions. Only local variables and
functions could be accessed without a prefix. If we approve this proposal
then maybe this is a great idea, or maybe this example shows some flaw in
the proposal. Either way, hopefully it can help us see the proposal in a
new light.

Daniel

···

On Thu, Dec 17, 2015 at 1:03 PM Michael Brown via swift-evolution < swift-evolution@swift.org> wrote:

On 17 Dec 2015, at 17:54, Dan Loewenherz <dan@lionheartsw.com> wrote:

On Thu, Dec 17, 2015 at 11:28 AM, Michael Brown via swift-evolution < > swift-evolution@swift.org> wrote:

On Tue, Dec 15, 2015 at 21:03 Sune Foldager via swift-evolution < >> swift-evolution@swift.org> wrote:

> “self.” everywhere means you can see what’s an instance member and
what’s a local variable. That’s generally a good thing. But it also means a
lot of filler text in your code, which makes reading and writing slower.
That’s not so good. It’s a balance, and in this case my experience from C#
(and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of
“this”/“self".
>
> I see that this proposal is going to be reviewed as SE-0009, and I am a
bit concerned that not all arguments are being considered because of the
contents of the proposal text: The only counter argument mentioned in the
proposal has to do with capturing semantics in closures. This is fine, but
why isn’t the counter argument of verbosity being mentioned? This has been
brought up on the list as well.
>

I couldn't agree more on all points. I strongly object to this proposal.
Requiring self makes code unnecessarily verbose and is one of the things I
least liked about Objective-C compared to other languages (e.g. C#, Python,
Java) where the use of self/this is optional. It is only only actually
necessary when resolving ambiguity with local variables, in the few
situations where such ambiguity exists (initialisers mostly).

Correction: self is not optional in Python.

Yes. I realized my mistake soon after I hit send. Apologies.

Michael.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Paul Ossenbruggen) #5

This may have been covered in the past but is there any reason why we can’t require use “.property”? It would work similar to the way you can use “.property” in enums. This would be terse, consistent with enum, and would help the call site be more explicit. This would be the same as self.property. I would not mind having that in my call sites.

···

On Dec 17, 2015, at 11:53 AM, Daniel Hooper via swift-evolution <swift-evolution@swift.org> wrote:

I have mixed feelings about this proposal: I see some value in the problems it is trying to address, though there are other ways to solve them.

The two problems it tried to address that I consider legitimate:
1. bullet proofing against bugs.
The example in the motivation section is a good one. I can imagine this happening, though I haven't ever personally experienced it, so how often does it really happen? Is it often enough to warrant this requirement? The root cause of that bug is that the instance variable was shadowed by a local one. Requiring self is one way to ensure local variables don't shadow instance variables, but the compiler could also just disallow shadowing instance variables. Details aside, the take away here is that there are other solutions to this problem.

2. Clarity at the call site.
Syntax highlighting solves this with two caveats: color blindness and non-colored code, such as diffs in the terminal. Color blindness can be helped by changing the coloring rules to make it easier to differentiate ivars. I don't have an answer for situations with no syntax coloring, though in my own workflow that isn't really an issue. For teams that it is, they could require use of self, or ivar prefixes ("var _ivar")

So while both problems could be legitimate, there are other ways of addressing them that don't require the verbosity of "self."

Thought experiment:
"self." has a lot of baggage from obj-c, python, etc, so as an experiment let's extended this proposal to it's logical conclusion and see how we feel about it: Global variables and functions have this same shadowing situation that ivars and instance methods do: an identifier without "self." could be referencing a local or global variable. Here is the same example from the proposal, but with a global variable instead of the ivar:

let greeting = "Hi There"
class MyViewController : UIViewController {
    @IBOutlet var button: UIButton!

    func updateButton() {
        // var greeting = "Good morning"
        button.setTitle(greeting, forState: .Normal) // forgot to comment this line but the compiler does not complain and greeting is now referencing global greeting by mistake
    }
}

By this proposal's logic we should create a "global." prefix and require it to access global variables and functions. Only local variables and functions could be accessed without a prefix. If we approve this proposal then maybe this is a great idea, or maybe this example shows some flaw in the proposal. Either way, hopefully it can help us see the proposal in a new light.

Daniel

On Thu, Dec 17, 2015 at 1:03 PM Michael Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 17 Dec 2015, at 17:54, Dan Loewenherz <dan@lionheartsw.com <mailto:dan@lionheartsw.com>> wrote:

On Thu, Dec 17, 2015 at 11:28 AM, Michael Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Tue, Dec 15, 2015 at 21:03 Sune Foldager via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> “self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".
>
> I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.
>

I couldn't agree more on all points. I strongly object to this proposal. Requiring self makes code unnecessarily verbose and is one of the things I least liked about Objective-C compared to other languages (e.g. C#, Python, Java) where the use of self/this is optional. It is only only actually necessary when resolving ambiguity with local variables, in the few situations where such ambiguity exists (initialisers mostly).

Correction: self is not optional in Python.

Yes. I realized my mistake soon after I hit send. Apologies.

Michael.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Radek Pietruszewski) #6

Ambiguous in two cases:
- when passing an argument (is this implied self, or implied type? — clashes with shortcut for enums etc)
- starting the line with a dot now allows you to continue the method chain from the previous line.

— Radek

···

On 19 Dec 2015, at 01:50, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

This may have been covered in the past but is there any reason why we can’t require use “.property”? It would work similar to the way you can use “.property” in enums. This would be terse, consistent with enum, and would help the call site be more explicit. This would be the same as self.property. I would not mind having that in my call sites.

On Dec 17, 2015, at 11:53 AM, Daniel Hooper via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have mixed feelings about this proposal: I see some value in the problems it is trying to address, though there are other ways to solve them.

The two problems it tried to address that I consider legitimate:
1. bullet proofing against bugs.
The example in the motivation section is a good one. I can imagine this happening, though I haven't ever personally experienced it, so how often does it really happen? Is it often enough to warrant this requirement? The root cause of that bug is that the instance variable was shadowed by a local one. Requiring self is one way to ensure local variables don't shadow instance variables, but the compiler could also just disallow shadowing instance variables. Details aside, the take away here is that there are other solutions to this problem.

2. Clarity at the call site.
Syntax highlighting solves this with two caveats: color blindness and non-colored code, such as diffs in the terminal. Color blindness can be helped by changing the coloring rules to make it easier to differentiate ivars. I don't have an answer for situations with no syntax coloring, though in my own workflow that isn't really an issue. For teams that it is, they could require use of self, or ivar prefixes ("var _ivar")

So while both problems could be legitimate, there are other ways of addressing them that don't require the verbosity of "self."

Thought experiment:
"self." has a lot of baggage from obj-c, python, etc, so as an experiment let's extended this proposal to it's logical conclusion and see how we feel about it: Global variables and functions have this same shadowing situation that ivars and instance methods do: an identifier without "self." could be referencing a local or global variable. Here is the same example from the proposal, but with a global variable instead of the ivar:

let greeting = "Hi There"
class MyViewController : UIViewController {
    @IBOutlet var button: UIButton!

    func updateButton() {
        // var greeting = "Good morning"
        button.setTitle(greeting, forState: .Normal) // forgot to comment this line but the compiler does not complain and greeting is now referencing global greeting by mistake
    }
}

By this proposal's logic we should create a "global." prefix and require it to access global variables and functions. Only local variables and functions could be accessed without a prefix. If we approve this proposal then maybe this is a great idea, or maybe this example shows some flaw in the proposal. Either way, hopefully it can help us see the proposal in a new light.

Daniel

On Thu, Dec 17, 2015 at 1:03 PM Michael Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 17 Dec 2015, at 17:54, Dan Loewenherz <dan@lionheartsw.com <mailto:dan@lionheartsw.com>> wrote:

On Thu, Dec 17, 2015 at 11:28 AM, Michael Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Tue, Dec 15, 2015 at 21:03 Sune Foldager via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> “self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".
>
> I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.
>

I couldn't agree more on all points. I strongly object to this proposal. Requiring self makes code unnecessarily verbose and is one of the things I least liked about Objective-C compared to other languages (e.g. C#, Python, Java) where the use of self/this is optional. It is only only actually necessary when resolving ambiguity with local variables, in the few situations where such ambiguity exists (initialisers mostly).

Correction: self is not optional in Python.

Yes. I realized my mistake soon after I hit send. Apologies.

Michael.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution