> Karen Stone wrote: >> I believe there’s real value in being explicit about referencing class >> members. It helps both the reader of the code and it makes writing code >> with typical IDE conveniences like code completion less cluttered and more >> informative. Unfamiliar class methods won’t be included in lists of >> suggestions where they might look like they operate on the current instance.
But it's not required of instance members, and frankly I hope it never is. I don't want to have to write self.foo() (and find it a bit weird that I have to in closures defined within the context of a class, when there's only one possible self that one could be referring to). I've finally gotten used to writing self.instanceVar, but only because Swift really resists naming by scope (e.g. mInstanceVar), and I wanted something to clearly identify when I'm referencing an instance variable rather than some possible local variable. (I'm a huge proponent of styling the name of things after their scope, but I also like doing that as compactly as possible. In C++, this meant prefixing variable names according to their scope (e.g. m, s, k, q). In Swift, when you have to write self.mInstanceVar, it just bugs me, and is rather redundant, so I've modified my personal style rules. Anyway, this is a huge digression. I guess I'm saying there's no consistent requirement in Swift, so saying it's helpful to call it out for class statics doesn't seem to hold much water.) -- Rick Mann rm...@latencyzero.com _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
