[swift-evolution] SE-0025: Scoped Access Level, next steps

[Ted F.A. van Gaalen]

Oops here it is again: error in example 
On 28.03.2016, at 23:52, Ted F.A. van Gaalen <tedvgiosdev at gmail.com> wrote:

Hello Joanna, seems you are quite new to programming, just kidding, so sad you’ve missed the punch card era,
a lot of fun, but I cannot take you back there because my Delorean is broken :o)

Seriously, thank you for writing this, I share your opinion:

> In the light of the preceding paragraphs, I would, respectfully, suggest that "protected" should be allowed for exclusive use in the case of classes that really have to derive from each other, but for no other reason.
Exactly !
> Likewise, "private" should mean what it has meant and still means in most other languages, members of classes only, since, like "protected", that is its true nature.
Yes.
> 
> What Swift presently calls "internal" seems to equate more to the C# concept of "internal" and, in my mind, needs no further discussion or change.
> 
> Just as I was never happy with the Delphi concept of private and protected members being accessible, not just in the class or its derived types, but also from any code in the same code unit, I feel uneasy about the present definition of the private scope in Swift.
> 
Me too.
> I have seen some horrendous abuses of that privileged access, with the gradual growth of single code units to truly gargantuan proportions, just because someone felt that certain classes needed to violate all the rules of common sense and be able to access each others' private parts (if you'll pardon the vernacular).
> 
> 
> 
Especially this, couldn’t agree more:
> Personally, I would like to see the end of the file based scope and, instead, see more clearly defined "privileged" access between types, even if they are in the same code unit.

I would suggest the (true) use of “namespaces”, instead of file based scope,
so that entities  *must*  be imported or qualified by namespace.

When I started with Swift, i was under the false impression that Swift concatenates all the sources in a project and simply treat this
as one single source file…

To my knowledge there is no way to hide class members. This is not good !
I’d like to show how i prefer it in this example: 

“private” here means: only visible within the scope where it was declared!  Imho what private does now in Swift is
completely wrong. 
“Protected” is here: like private but visible in descendants as well 

namespace Eriador
{
class Mithril       // This class is not visible outside the namespace.                 
{                   // a + b
    var a = 0.0     // should not visible outside this class/instance
    private var b = 1.0    // “private”is the default
    public var c = 1.0     // is visible outside the class
    protected var d = “My precious…”  // is also visible in descendants
    
    init()
    {
        forgeRing()
    }
    
    // to use this function outside, it should be preceeded
    // by a "public" keyword, like it is in Java:

    public func stridingToMordor() -> Double
    {
        return a + b + c
    }
}

} // end namespace Eriador
--------------------------------------------------------
//in another file
#import Foundation

namespace Rohan
{
  #import namespace Eradior

func quest()
 {
   var mi = Mithril()
   mi.a = 10.0          // Error:  “a" and “b" are 
   mi.b = 10.0          // not public members of Mithril      
   mi.c = 12345.67      // ok 

   print(mi.stridingToMordor()) // ok
 }
}

Just my two cents to this ever lasting theme:
can’t see the wood for the trees anymore.
TedvG



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