Comments (13)
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.
from vapor.
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.
from vapor.
I agree, self should be removed to reduce bugs.
from vapor.
I'm all for a revisit, I'm personally not a fan, but have been using self.
for consistency of style.
from vapor.
@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.
from vapor.
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.
from vapor.
@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.
from vapor.
I think the rejection rationale makes a strong case against explicit self, which is why I see it as a recommendation not to use
self` 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.
from vapor.
@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.
from vapor.
@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.
from vapor.
@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..
from vapor.
@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.
from vapor.
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.
from vapor.
Related Issues (20)
- commùit
- Double slash in URLs still breaks route matching with variable parts in vapor 4.92.0 HOT 2
- Trying to build on Ubuntu 20 with swift run and getting Building for debugging... error: emit-module command failed due to signal 9 HOT 2
- Unable to shutdown server HOT 1
- Title
- Vapor URLQueryContainer no longer supports valueless query parameters HOT 4
- Swift Vapor-Save records in Mysql JSON data type during mapping with swift get error- Could not convert MySQL data to String: <MYSQL_TYPE_JSON HOT 6
- Large, streamed request body may result in noSignalReceived preconditionFailure crash HOT 6
- Websocket shouldUpgrade() fail causes empty reply from server HOT 4
- Cannot setup a route returning `[Int: String]` HOT 7
- Log actual port when it's picked by the OS
- 'Flag' URL Query params don't decode into structs HOT 3
- HEAD response should allow non-zero Content-Length HOT 3
- Authentication Cache + Storage crash application HOT 2
- Default to `HTTPClient.shared` when possible HOT 1
- URLFormEncoder does not escape all reserved characters HOT 3
- Return 415 error if compressed request is detected, but not supported
- Crash after installing posix ELG as concurrency executor HOT 1
- Stored property '_id' of 'Sendable'-conforming class 'Todo' is mutable HOT 3
- [routes] does not split path parameter by '/' HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vapor.