Use of `self` about vapor

[shnhrrsn]

This is consistent throughout Vapor, not isolated to this specific case. We had a discussion on this a few weeks ago and opted to continue using self. for the sake of clarity, despite the guidelines.

[svanimpe]

I think that's a very bad idea and a dangerous precedent. There's been enough discussion about this proposal on the mailing lists and it has been ultimately rejected. Vapor should not place itself above this. Practices that go against Swift's accepted guidelines will only deter possible contributors. I know I would think twice about spending time on a project that doesn't care enough about Swift to follow its guidelines.

[ketzusaka]

I agree, self should be removed to reduce bugs.

[loganwright]

I'm all for a revisit, I'm personally not a fan, but have been using self. for consistency of style.

[shnhrrsn]

@ketzusaka: What bugs does using self. introduce? The rejection posting on this seemed to be philosophical, not technological, mainly around "visual clutter".

@svanimpe: I'd say this is an exception, not a rule. We generally follow Swift guidelines, we're not going around actively seeking them out to break.

From the rejection posting:

This proposal spawned a massive, polarized discussion with 200+ messages involving 80+ participants. We’re thrilled at the enthusiasm and thank all who participated. There were many, many interesting points made, along with experience reports from various Swift code bases, ideas to help mitigate the concerns that motivated the proposal, and so on. Quantitatively, the overall community assessment of the proposal was roughly 5:2 against requiring “self.”.

And:

• Individuals or teams that feel that explicit “self.” is beneficial for their own code bases can enforce such a coding convention via tooling with the status quo. If this proposal were accepted, those opposed to the proposal would effectively have no recourse because the language itself would be enforcing “self.”.

Unless I'm misunderstanding, by not accepting the proposal to require self., it was left up to individual projects to decide whether to use it. If it had been accepted, there wouldn't be an option and everyone would be forced to use self.. While I prefer self., I'd oppose a proposal to require it as well.

Either way, when I jump into open source projects I follow what's been established in the project itself. If Vapor switches to dropping self., I'll begrudgingly follow along. My vote though, would be to continue using it as I find it impossible to follow code without it.

[tanner0101]

The proposal is against requiring the use of self.. It doesn't mention anything about recommended style. If there are some important points from the mailing list about why using self. is bad, then I'm interested to hear them.

But being clear that you are using a member variable vs a local variable has a lot of utility. Take the following example.

class Foo {
    var bar: String

    func baz() {
        /* Various code here */

        //I want to add to the member variable here
        bar += "..." 
    }
}

Some time later...

class Foo {
    var bar: String

    func baz() {
        //Other dev adds local variable
        //They have no idea this is going to change
        //the functionality of the code below
        var bar = "" 

        /* Various code here */

        //Now this is not working
        bar += "..." 
    }
}

Additionally, there's a reason C and Java have best practices of including something like m before member variables. It's really nice to know when reading code what it is referencing.

[ketzusaka]

@tannernelson Your example is why we write tests in the first place.

@shnhrrsn The key bug commonly introduced by always using self is retain cycles, which is scary to for a server program. See: http://www.magicalpenguin.com/blog/stop-using-self-for-methods-and-properties

The use of self within the codebase was extremely frightening to me when I first looked at Vapor. self always feels unnecessary, and often leads to bugs like the one mentioned in the above blog post.

[svanimpe]

I think the rejection rationale makes a strong case against explicit self, which is why I see it as a recommendation not to useself` unless necessary (and not just as a rejection of requiring it).

In all my years (15) of programming, I have never ever written a single bug that could have been solved by using explicit self. Any decent IDE or editor should make it clear if you're referencing a property or a local variable. I wholeheartedly agree with the rationale that explicit self adds nothing but visual clutter, which is annoying to write and makes code harder to read and understand.

@tannernelson: Prefixes like m are actually frowned upon in Java.

[shnhrrsn]

@ketzusaka I'm not sure I buy this as a good reason, if you're always used to using self in closures, you're going to end up doing it anyway.

[tanner0101]

@svanimpe Can you please supply a link to the rejection rationale? From SE-9 all I can see are reasons to use self. The community response section is full of good reasons.

[ketzusaka]

@shnhrrsn you don't always use self in closures. i think it's on the rarer side.

Swift has always been about safer code. Explicit use of self goes against that..

[svanimpe]

@tannernelson The rejection rationale can be found here.

Again, I think everyone who followed the discussion understood that this wasn't so much about the proposal as it as was a discussion about whether self should or shouldn't be required. The rejection clearly indicates that it shouldn't.

[tanner0101]

Mandatory “self.” introduces a significant amount of verbosity that does not justify itself with added clarity. While it is true that mandatory “self.” may prevent a class of bugs, the cost of eliminating those bugs is fairly high in terms of visual clutter, which goes against the generally uncluttered feel of Swift.

Well that's pretty clear.

If that is where the Swift team stands, then Vapor should follow. Despite my personal preference.