+1 for member variables, -1 for member functions. Functions take up too much vertical space to make this convenient; you’d constantly be scrolling around to view or modify the access level of a function. Plus I tend to group functions by use — private functions go directly above the public function that calls them. But member declarations are often one or just a few lines, and additionally are often grouped by access level anyway (at least that’s how I do it) so this provides a compact way to group them.
> On Jun 17, 2017, at 5:48 PM, Ted F.A. van Gaalen via swift-evolution > <[email protected]> wrote: > > (I am not sure if I should tag this subject with [pitch]? ) > > Please don’t worry , I am not attempting to start a new > and infinite thread about whether or not the way scope > is handled in Swift is imho correct or not. > Errhm well, apart from that “protected” is missing, > but please let us not start again.. :o) > > No, it is more or less a convenience solution to > prevent unnecessary wear and tear to the following keys > on my keyboard: [ A,E, I, P, R, T, V] > > I prefer it, not to expose those class or struct members > which should not be accessible outside the class or struct > > Currently, to prevent access to private Items, > I have to type the word “private” too many times: > > class House > { > private var rooms = 5 > private var roofTiles = 11201 > private let paint = UIColor.Blue; > private var yearTax: Money = “323,56" > private let garageVolume = 60.0 > > init(..) {.. } > > private func calculateTax() {...} > > public func roomsUnoccupied() -> Int {…} > > func roofData(……) {…} > > private func a{…} > } > > To set the scope of a list of members I suggest the > “in-line scope modifiers” (anyone with a better name for it?) > > For example if one has a source line containing the word > “private:” then all the following member declarations will > be “private” until another inline scope modifier is encountered > with one “default scope” to escape from it. like in the following example” > > The compiler can detect that it is an inline scope modifier, because it ends > with a colon > > “Normal” scope modifiers, that is the ones which precede the member’s name > directly should imho not be allowed within such a scope block. > unless they would override for that specific item, but that looks ugly. > > getter & setters and init should appear in default scope > (or with no in-line scope modifiers) > > Inline scope modifiers can be specified as often as > desired and in arbitrary sequence. > > > class House > { > init(..) {.. } > private: // <—— In-line scope > modifier all following declarations are private here. > var rooms = 5 > var roofTiles = 11201 > let paint = UIColor.Blue; > var yearTax: Money = “323,56" > func calculateTax() {…} > func a{…} > > public: // <—— In-line > scope modifier > var garageVolume = 60.0 > func roomsUnoccupied() -> Int {…} > func roofData(……) {…} > > defaultscope: // <—— Return to default > scope (only needed when preceding inline scope modifiers are present. ) > > func sellHouse(buyer: CustomerID) > } > > See? looks a lot better, don’t you think so? > it also makes sources more readable because one can > now conveniently group items. > > 100% source compatible with whatever scope > mechanism now or in the future is or will be deployed. > > > (The idea is not exactly new, a similar construct is available in Object > Pascal.) > > ? > > Kind Regards > TedvG > > > > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
