[swift-evolution] SE-0025: Scoped Access Level, next steps
Ted F.A. van Gaalen
tedvgiosdev at gmail.com
Mon Mar 28 16:52:58 CDT 2016
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 Aragorn
mi.c = 12345.67 // ok
print(ar.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/20160328/00268dcb/attachment.html>
More information about the swift-evolution
mailing list