[swift-evolution] In-line scope designators

[Ted F.A. van Gaalen]

Hi Robert,

This would be an optional feature, can be left out. 
if one doesn’t use it nothing changes.
Although imho it looks better, the primary intent
is to hide/protect  members, be it vars, functions,
from outside access, without having to type scope
qualifiers on most of my source lines.
As you can see, personally I use vertical space a lot:
brackets on new lines, empty lines, etc.
I use a Mac Mini with a a 4K screen and a relative small font
(and reading glasses :o) thus having to scroll very little.

Kind Regards
TedvG

 
 
> On 19. Jun 2017, at 20:45, Robert Bennett <rltbennett at icloud.com> wrote:
> 
> +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 <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170619/5f3fbe7f/attachment.html>