access control


(Carlos Rodriguez Dominguez) #1

I agree with some contributors of this thread in the sense that current “private” modifier is really confusing for newcomers. I think one of the objectives of Swift is to try to attract new developers, and most developers come from Java-based platforms. Therefore, using the same modifier name as in Java, but to refer to different access control semantics, could mislead its use. In my opinion, “private” should have the same semantics as some people are proposing for the new “local” modifier. On the other hand, the new “local” modifier should be a replacement of the current “private” modifier, in order to support a similar approach to “friend classes” in c++ (as it really happens right now with that access control).


(Jean-Daniel) #2

FWIW, I don’t like the ‘local’ term as ‘local variable’ is already widely used for in very specific sens.

While ‘local’ member variable may look like standard local variable as they are supposed to be scoped restricted, the fact that they are available in extension means they are not limited to the class scope and so don’t have the same meaning than existing local variables.

···

Le 29 janv. 2016 à 13:04, Carlos Rodríguez Domínguez via swift-evolution <swift-evolution@swift.org> a écrit :

I agree with some contributors of this thread in the sense that current “private” modifier is really confusing for newcomers. I think one of the objectives of Swift is to try to attract new developers, and most developers come from Java-based platforms. Therefore, using the same modifier name as in Java, but to refer to different access control semantics, could mislead its use. In my opinion, “private” should have the same semantics as some people are proposing for the new “local” modifier. On the other hand, the new “local” modifier should be a replacement of the current “private” modifier, in order to support a similar approach to “friend classes” in c++ (as it really happens right now with that access control).

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ilya Belenkiy) #3

The proposal is to hide everything marked with "local" inside the lexical
scope, which means from extensions (or even from other extensions) as well.
In that sense, the name fits very well. The name itself could be different
(for example, it could be named "private", and private could be named "file
internal" or something similar). The primary goal is the additional
modifier to express the access level. I proposed "local" because it doesn't
require any changes to existing code or the documentation.

···

On Fri, Jan 29, 2016 at 12:08 PM Jean-Daniel Dupas via swift-evolution < swift-evolution@swift.org> wrote:

FWIW, I don’t like the ‘local’ term as ‘local variable’ is already widely
used for in very specific sens.

While ‘local’ member variable may look like standard local variable as
they are supposed to be scoped restricted, the fact that they are available
in extension means they are not limited to the class scope and so don’t
have the same meaning than existing local variables.

> Le 29 janv. 2016 à 13:04, Carlos Rodríguez Domínguez via swift-evolution > <swift-evolution@swift.org> a écrit :
>
> I agree with some contributors of this thread in the sense that current
“private” modifier is really confusing for newcomers. I think one of the
objectives of Swift is to try to attract new developers, and most
developers come from Java-based platforms. Therefore, using the same
modifier name as in Java, but to refer to different access control
semantics, could mislead its use. In my opinion, “private” should have the
same semantics as some people are proposing for the new “local” modifier.
On the other hand, the new “local” modifier should be a replacement of the
current “private” modifier, in order to support a similar approach to
“friend classes” in c++ (as it really happens right now with that access
control).
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution