Future(of: self.references)?


(Travis Griggs) #1

I’m trying to figure out how to ask this question without generating flame and heat. Like tabs and spaces, under_scores and camelCase, whether or not one thinks that a message dispatch receiver should be explicit or implicit seems to be highly personal, (I think*) based on where/how you learned programming, especially object oriented paradigms. Personally, I agree with Matt Neuberg and this Swift proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md). But I recognize there’s a community of others out there that think otherwise, and I’m not interested in trying to convert them to my approach.

What I *am* curious about is is what the core contributors/architects/designers seem to prefer? Is there any sort of consensus, or at least majority, that those doing the core work lean towards? They don’t have to convince me or vice versa. It’s just frustrating when collaborating with open source projects, that in this one area, there’s really no direction I’ve seen come forth.

For example, when Swift was waffling between functional and message oriented, I heard Chris Lattner (and have since seen in style guides) recommendations that if you can bind some behavior to data, you should, rather than leaving it a free function. That was nice to hear, and not just because I agreed. It was just nice to know which way the language would be leaning.


(Greg Power) #2

Hi Travis,

I’m certainly not a core contributor, but I could point you to the rejection email for this proposal, which you might not have seen:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html

It states that the core team felt that the proposal was not the right direction for Swift, and lists a few reasons.

The main reason appears to be that enforcing a mandatory self for instance members would increase the visual clutter of the language, which is counter to Swift's goals of clarity and minimal boilerplate.

That email links to Paul Cantrell’s response to the proposal, which is also a really good (and elucidating) read: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html.

No need for flame or heat!

Regards,

Greg Power

···

On 23 May 2017, at 7:28 am, Travis Griggs via swift-users <swift-users@swift.org> wrote:

I’m trying to figure out how to ask this question without generating flame and heat. Like tabs and spaces, under_scores and camelCase, whether or not one thinks that a message dispatch receiver should be explicit or implicit seems to be highly personal, (I think*) based on where/how you learned programming, especially object oriented paradigms. Personally, I agree with Matt Neuberg and this Swift proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md). But I recognize there’s a community of others out there that think otherwise, and I’m not interested in trying to convert them to my approach.

What I *am* curious about is is what the core contributors/architects/designers seem to prefer? Is there any sort of consensus, or at least majority, that those doing the core work lean towards? They don’t have to convince me or vice versa. It’s just frustrating when collaborating with open source projects, that in this one area, there’s really no direction I’ve seen come forth.

For example, when Swift was waffling between functional and message oriented, I heard Chris Lattner (and have since seen in style guides) recommendations that if you can bind some behavior to data, you should, rather than leaving it a free function. That was nice to hear, and not just because I agreed. It was just nice to know which way the language would be leaning.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Tino) #3

Well, sometimes it might be important that you are dealing with an instance variable, and in other cases, it's just clutter:
struct Triangle {
  var a: Float
  var b: Float
  var c: Float

  var isSquare: Bool {
    return self.a * self.a + self.b * self.b == self.c * self.c
  }

  var isStillSquare: Bool {
    return a * a + b * b == c * c
  }
}
Imho the second variant is clearly better than the first, and it would be bad to enforce self.

My personal rule of thumb for this is: Use the self prefix for things that should change self, skip it for read-only access — but the exact "rules" are quite arcane, and I think the compiler shouldn't have to deal with complicated rules that still would fail to make everyone happy.
So, I think the current approach is the best we can do.


(Charles Srstka) #4

While this makes sense in principle, it is far too easy to accidentally access the wrong member because something was shadowed. The very fact that the core team had to add a special-case warning for NSView.print() to the compiler itself demonstrates how problematic this can be.

Oh well. When the core team rejected the proposal, part of the rationale was that this could be done with a linter; does anyone know if anything to do this was ever written as an Xcode extension? As coincidence would have it, I ran into an issue caused by the implicit ‘self.’ behavior just yesterday.

Charles

···

On May 23, 2017, at 12:00 AM, Kelvin Ma via swift-users <swift-users@swift.org> wrote:

As someone who is very in favor of using `self` everywhere, I’ve come to the conclusion that the easiest way to use `self` everywhere is to write `self` everywhere. I write Swift as if `self` were mandatory, and as that email argues, that’s good enough for me. Personally I find self-less code harder to read, but it’s not a big enough difference for me to argue for pushing it on everyone else.

On Mon, May 22, 2017 at 8:56 PM, Greg Power via swift-users <swift-users@swift.org> wrote:
Hi Travis,

I’m certainly not a core contributor, but I could point you to the rejection email for this proposal, which you might not have seen:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html

It states that the core team felt that the proposal was not the right direction for Swift, and lists a few reasons.

The main reason appears to be that enforcing a mandatory self for instance members would increase the visual clutter of the language, which is counter to Swift's goals of clarity and minimal boilerplate.

That email links to Paul Cantrell’s response to the proposal, which is also a really good (and elucidating) read: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html.

No need for flame or heat!

Regards,

Greg Power

On 23 May 2017, at 7:28 am, Travis Griggs via swift-users <swift-users@swift.org> wrote:

I’m trying to figure out how to ask this question without generating flame and heat. Like tabs and spaces, under_scores and camelCase, whether or not one thinks that a message dispatch receiver should be explicit or implicit seems to be highly personal, (I think*) based on where/how you learned programming, especially object oriented paradigms. Personally, I agree with Matt Neuberg and this Swift proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md). But I recognize there’s a community of others out there that think otherwise, and I’m not interested in trying to convert them to my approach.

What I *am* curious about is is what the core contributors/architects/designers seem to prefer? Is there any sort of consensus, or at least majority, that those doing the core work lean towards? They don’t have to convince me or vice versa. It’s just frustrating when collaborating with open source projects, that in this one area, there’s really no direction I’ve seen come forth.

For example, when Swift was waffling between functional and message oriented, I heard Chris Lattner (and have since seen in style guides) recommendations that if you can bind some behavior to data, you should, rather than leaving it a free function. That was nice to hear, and not just because I agreed. It was just nice to know which way the language would be leaning.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

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


(^) #5

As someone who is very in favor of using `self` everywhere, I’ve come to
the conclusion that the easiest way to use `self` everywhere is to write
`self` everywhere. I write Swift as if `self` were mandatory, and as that
email argues, that’s good enough for me. Personally I find self-less code
harder to read, but it’s not a big enough difference for me to argue for
pushing it on everyone else.

···

On Mon, May 22, 2017 at 8:56 PM, Greg Power via swift-users < swift-users@swift.org> wrote:

Hi Travis,

I’m certainly not a core contributor, but I could point you to the
rejection email for this proposal, which you might not have seen:

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20160104/005478.html

It states that the core team felt that the proposal was not the right
direction for Swift, and lists a few reasons.

The main reason appears to be that enforcing a mandatory *self* for
instance members would increase the visual clutter of the language, which
is counter to Swift's goals of clarity and minimal boilerplate.

That email links to Paul Cantrell’s response to the proposal, which is
also a really good (and elucidating) read: https://lists.swift.org/
pipermail/swift-evolution/Week-of-Mon-20151214/002910.html.

No need for flame or heat!

Regards,

Greg Power

On 23 May 2017, at 7:28 am, Travis Griggs via swift-users < > swift-users@swift.org> wrote:

I’m trying to figure out how to ask this question without generating flame
and heat. Like tabs and spaces, under_scores and camelCase, whether or not
one thinks that a message dispatch receiver should be explicit or implicit
seems to be highly personal, (I think*) based on where/how you learned
programming, especially object oriented paradigms. Personally, I agree with
Matt Neuberg and this Swift proposal (https://github.com/apple/
swift-evolution/blob/master/proposals/0009-require-self-
for-accessing-instance-members.md). But I recognize there’s a community
of others out there that think otherwise, and I’m not interested in trying
to convert them to my approach.

What I *am* curious about is is what the core contributors/architects/designers
seem to prefer? Is there any sort of consensus, or at least majority, that
those doing the core work lean towards? They don’t have to convince me or
vice versa. It’s just frustrating when collaborating with open source
projects, that in this one area, there’s really no direction I’ve seen come
forth.

For example, when Swift was waffling between functional and message
oriented, I heard Chris Lattner (and have since seen in style guides)
recommendations that if you can bind some behavior to data, you should,
rather than leaving it a free function. That was nice to hear, and not just
because I agreed. It was just nice to know which way the language would be
leaning.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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


(Rien) #6

I will often use this rule: If a scope need to use ‘self’ at least once, then I will always use ‘self’ in that scope.
Otherwise I won’t use ’self’ at all.

There are always exceptions though, first and foremost: if the usage of ‘self’ hinders understandability of the code (interferes with self documentation), then don’t use it.
Also the usage of ‘self’ in a guard statement does not count.

Mostly though I will try and avoid the necessity for using ’self’ at all. It often is an indication that names are not correct or not optimal.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift

···

On 23 May 2017, at 11:30, Tino Heth via swift-users <swift-users@swift.org> wrote:

Well, sometimes it might be important that you are dealing with an instance variable, and in other cases, it's just clutter:
struct Triangle {
  var a: Float
  var b: Float
  var c: Float

  var isSquare: Bool {
    return self.a * self.a + self.b * self.b == self.c * self.c
  }

  var isStillSquare: Bool {
    return a * a + b * b == c * c
  }
}
Imho the second variant is clearly better than the first, and it would be bad to enforce self.

My personal rule of thumb for this is: Use the self prefix for things that should change self, skip it for read-only access — but the exact "rules" are quite arcane, and I think the compiler shouldn't have to deal with complicated rules that still would fail to make everyone happy.
So, I think the current approach is the best we can do.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Travis Griggs) #7

Thank you Greg (and others) for the replies. I don’t think much of the *rationale* stated there, especially actually Paul Cantrell’s. BUT, I can appreciate that it was a “contentious” issue. And as said, I didn’t come to stir the pot. Merely to get clarification.

I did my time in the language wars of the late 90’s and early 00’s. After a while, like real wars, I came to realize the pointlessness of a lot of it. Perspectives are huge, e.g. brevity of characters and brevity in consistency are two different things that can counter each other and be argued equally by both sides in the name of brevity. History repeats itself. Swift has lots to like.

It would be great if there was a switch in a tool like Xcode that would insert magical “self” bubbles for visual consistency wherever they appeared. But then… I’m still wondering if we’ll ever see refactoring tools emerge in Xcode for Swift (and beginning to lose hope).

···

On May 22, 2017, at 5:56 PM, Greg Power <gregp@blackmagicdesign.com> wrote:

Hi Travis,

I’m certainly not a core contributor, but I could point you to the rejection email for this proposal, which you might not have seen:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html

It states that the core team felt that the proposal was not the right direction for Swift, and lists a few reasons.

The main reason appears to be that enforcing a mandatory self for instance members would increase the visual clutter of the language, which is counter to Swift's goals of clarity and minimal boilerplate.

That email links to Paul Cantrell’s response to the proposal, which is also a really good (and elucidating) read: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002910.html.

No need for flame or heat!