-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using self #7
Comments
I agree, and I also agree it will be a bit hard at the beginning :) |
I agree with both of those agreements. So, down with self unless the compiler whines about it! Sent from my iPhone
|
What bothers me about ditching self is that there's no easy way to Don't u guys agree? On Tuesday, June 10, 2014, elephantronic notifications@github.com wrote:
|
Many editors that I have used highlight the two differently. Hopefully Xcode will follow with this feature. I'd only use |
Isn't the guide targeting our books and tutorials? I still think using self On Tuesday, June 10, 2014, ColinEberhardt notifications@github.com wrote:
|
Agreed that we should ditch |
Apple doesn't use it, so I don't think we should either. I'm not really happy with that decision on Apple's side, but I do think we should follow their conventions. |
I know I said down with self, and I think I still think that, but I just looked at the code in the Swift Sprite Kit game template. It's GameViewController uses self.view and self.classForKeyedUnarchiver. So that's an example of a property and a standard method, both using self. In the same class, I also found two instances of var that compiled fine as let. Hopefully their templates just aren't ready for prime time, but it does give me pause. I'd like to see how some of these things progress across the betas. |
I wouldn't put too much faith in Apple's templates or sample code. It's usually not the best example of how to do things... That same template also ends lines with a semicolon, for example. :-) |
Good point. We should probably add semicolons everywhere, too. ;) --------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7) I wouldn't put too much faith in Apple's templates or sample code. It's usually not the best example of how to do things... That same template also ends lines with a semicolon, for example. :-)Reply to this email directly or view it on GitHub. |
I believe self makes code much more clear. It makes it very easy to know whether it's a property or instance variable. Same reason I vote to always use self in objc for properties rather than using their instance variable _propertyName. |
self definitely makes it more clear while reading a code snippet. The real question is whether or not that extra clarity is worth it. If you type code that compiles, it compiles. Swift doesn't let you compile code that implicitly hides another variable/func from a different scope, so we don't need to say self because if the method is the only one in scope, it will compile. If it is on another object and this object, it will fail to compile until you specify which one you want (by using self, if necessary) Obj-C is the only language I've ever seen that asks people to specify that they own what they clearly own, so it's nice that Swift has done away with it. If you are writing a method, it shouldn't be hard to see which variables are local to that method. Outside of that method, scope only matters to the compiler. --------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7) I believe self makes code much more clear. It makes it very easy to know whether it's a property or instance variable. Same reason I vote to always use self in objc for properties rather than using their instance variable _propertyName.Reply to this email directly or view it on GitHub. |
I keep not agreeing with this thread. This style is supposed to be for the tutorial and book authors not a In the context of books and tuts where you can be adding few lines of code On Thursday, June 12, 2014, elephantronic notifications@github.com wrote:
|
I've written a pretty popular Unity tutorial. It uses C# and no selfs. I haven't heard complaints that people didn't understand where the variables were coming from. --------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7) I keep not agreeing with this thread. This style is supposed to be for the tutorial and book authors not a In the context of books and tuts where you can be adding few lines of code On Thursday, June 12, 2014, elephantronic notifications@github.com wrote:
|
The argument "it compiles then it's ok" is weak. I think we should find our style and stick to it. It's not a secret that I favor readability over a few more keys to type when it comes to tutorials. I vote for using self. |
Yes !!! Cesare is on readability side! We can do it! 4 more years! 4 more years! I mean - using self for class variables! On Thursday, June 12, 2014, Cesare notifications@github.com wrote:
|
Ok, how about this argument? The forced use of self is one of the things Apple removed when creating Swift because they saw how stupid it is and noticed every other language in the world doesn't need it and everyone seems to be ok with those, right? If Apple wanted to, they easily could have included self as a mandatory part of the language. They chose not to for the very good reason that it is completely unnecessary, and writing unnecessary extras in code generally makes things less readable in the long run. Obj-C was a language built on top of another language. Things like self were used to aid the bracket syntax to indicate an Obj-C function versus a C function. The compiler didn't understand true classes and such, so they had to build special syntax to trick it. It is no longer necessary, and holding onto it isn't going to help you or our readers. It will actually make things more difficult when you try to read other people's code because you will be so conditioned to seeing self that you won't interpret things correctly when you don't see it. Let go of the shackles of the past and embrace the future. You'll feel better. --------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7) The argument "it compiles then it's ok" is weak. I think we should find our style and stick to it. It's not a secret that I favor readability over a few more keys to type when it comes to tutorials. I vote for using self.Reply to this email directly or view it on GitHub. |
I see your point @elephantronic and I might agree with you but in 1-2 years. The only reason I propose to use self is that it's hard to me (and I suspect to many other people) to completely forget about the past. If you are an Objc dev you are used to self, if you are not you will NEED to be able to read (if not write) Objc code. Either way, self pops up. So I vote for using self "at the moment" and I propose to review this issue in a year or so when everybody is more acquainted with the language. |
I vote for not using |
Does it make sense to put this one to a vote? I think there have been some well thought-out arguments from each side. I'm a +1 for not using |
I'm also a +1 for not using I saw Go when I first looked at Swift, but the longer and harder I look, the more Java I see. |
+1 selfless |
Fair enough I accept the democratic verdict :) |
We agreed to not write the type because it is not needed. We agreed to use Swift's defaults on param names, because it's the default and it doesn't make sense to go out of the way to do something different from what Swift wants you to do in those cases. To eliminate the param names, you have to write extra code and then explain it. --------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7) Fair enough I accept the democratic verdict :)
|
|
Hi, sorry to reanimate the dead thread. I'd like to know how are you guys now feeling after ditching |
I've ditched it and never looked back. :) |
The raywenderlich.com books and tutorials have been selfless for 4 years now and nobody has had any specific complaints. |
While writing Swift code, I catch myself typing
self.propertyName
andself.method()
a lot. But in Swift (as in C++, C# and Java) using self is not necessary unless you're trying to resolve an ambiguous situation.I suggest we don't use
self
except for that purpose.The text was updated successfully, but these errors were encountered: