access control proposal


(Colin Cornaby) #1

(I'm reading the upstream discussion but I'll reply here.)

I don't know if I really like the pattern this is trying to support. I like that Swift makes it cleaner to include multiple types in a single Swift file. But I feel like this proposal is trying to take things too far the other way. Types that should should only see each other from a non "friends" role should be in separate files.

What's proposed doesn't really harm someone who likes the "multiple file" style directly, but I don't want to see projects where everything gets jammed into one file. I think keeping the scope of private (with no new keywords) to the same file encourages good coding practices.

I've really liked the balance Swift strikes in this case. I feel like this discussion is going to come down to opinion, but projects that I've worked in that have tried to over compact have always run into issues. I don't know if it's the role of the language to push an ideology either way, but personally I like the direction Swift is pushing. Files make for good scope boundaries.

···

On Dec 05, 2015, at 08:40 PM, Ilya via swift-evolution <swift-evolution@swift.org> wrote:

I think the it would help a great deal to have an access level modifier that is really private and visible only inside the class itself. Right now, the only way to hide implementation details for a class is to hide the class code in a separate file, which is very inconvenient for several reasons:

1) the meaning of the code changes depending on which file the class is in. It's very easy to accidentally expose class internal details and then call class elements that are meant to be used only inside the class. Having a keyword for class internals will allow the compiler to ensure that only the public API for the class is used from the outside world. The user can check types on his own, but it's better that the compiler does it automatically. Similarly, the user can check that only the proper APIs are called, but it's better that the compiler does it automatically.

2) accessibility by file structure may cause some really short files.

3) It's impossible to group related classes in one file but still hide implementation details inside each class

I think that it the best solution is to make private keyword do what it states -- keep the class element private to the class. But if it's really important to have a separate keyword for backward compatibility, it would be the next best thing.

--
Ilya Belenkiy

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


(Ilya Belenkiy) #2

Please take a look at the other posts today. I addressed this concern
earlier. In one sentence, just like you wouldn't want to put every
paragraph of a book or every section of an article in an encyclopedia in a
separate file, you wouldn't want to end up with a gazillion files just to
ensure that implementation details of an API stay hidden in a way that is
enforced by the compiler.

···

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 2:19 PM Colin Cornaby via swift-evolution < swift-evolution@swift.org> wrote:

(I'm reading the upstream discussion but I'll reply here.)

I don't know if I really like the pattern this is trying to support. I
like that Swift makes it cleaner to include multiple types in a single
Swift file. But I feel like this proposal is trying to take things too far
the other way. Types that should should only see each other from a non
"friends" role should be in separate files.

What's proposed doesn't really harm someone who likes the "multiple file"
style directly, but I don't want to see projects where everything gets
jammed into one file. I think keeping the scope of private (with no new
keywords) to the same file encourages good coding practices.

I've really liked the balance Swift strikes in this case. I feel like this
discussion is going to come down to opinion, but projects that I've worked
in that have tried to over compact have always run into issues. I don't
know if it's the role of the language to push an ideology either way, but
personally I like the direction Swift is pushing. Files make for good scope
boundaries.

On Dec 05, 2015, at 08:40 PM, Ilya via swift-evolution < > swift-evolution@swift.org> wrote:

I think the it would help a great deal to have an access level modifier
that is really private and visible only inside the class itself. Right now,
the only way to hide implementation details for a class is to hide the
class code in a separate file, which is very inconvenient for several
reasons:

1) the meaning of the code changes depending on which file the class is
in. It's very easy to accidentally expose class internal details and then
call class elements that are meant to be used only inside the class. Having
a keyword for class internals will allow the compiler to ensure that only
the public API for the class is used from the outside world. The user can
check types on his own, but it's better that the compiler does it
automatically. Similarly, the user can check that only the proper APIs are
called, but it's better that the compiler does it automatically.

2) accessibility by file structure may cause some really short files.

3) It's impossible to group related classes in one file but still hide
implementation details inside each class

I think that it the best solution is to make private keyword do what it
states -- keep the class element private to the class. But if it's really
important to have a separate keyword for backward compatibility, it would
be the next best thing.

--
Ilya Belenkiy

_______________________________________________
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


(joe) #3

I've only cursorily followed this thread, but with the introduction of the Swift Package Manager, I'm guessing it will have a role to play in reducing the number of files one needs to be concerned with at any one time. If one has such an overwhelming number of files, it's probably likely that they could be split up into separate packages/modules. I'm not sure how much that has been considered in regards to worry of ending up with too many separate files.

And even assuming one runs into cases where there are loads of .swift files, at least it's still basically half of what there would be in Objective-C :slight_smile:

···

On Dec 14, 2015, at 1:42 PM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

Please take a look at the other posts today. I addressed this concern earlier. In one sentence, just like you wouldn't want to put every paragraph of a book or every section of an article in an encyclopedia in a separate file, you wouldn't want to end up with a gazillion files just to ensure that implementation details of an API stay hidden in a way that is enforced by the compiler.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 2:19 PM Colin Cornaby via swift-evolution <swift-evolution@swift.org> wrote:
(I'm reading the upstream discussion but I'll reply here.)

I don't know if I really like the pattern this is trying to support. I like that Swift makes it cleaner to include multiple types in a single Swift file. But I feel like this proposal is trying to take things too far the other way. Types that should should only see each other from a non "friends" role should be in separate files.

What's proposed doesn't really harm someone who likes the "multiple file" style directly, but I don't want to see projects where everything gets jammed into one file. I think keeping the scope of private (with no new keywords) to the same file encourages good coding practices.

I've really liked the balance Swift strikes in this case. I feel like this discussion is going to come down to opinion, but projects that I've worked in that have tried to over compact have always run into issues. I don't know if it's the role of the language to push an ideology either way, but personally I like the direction Swift is pushing. Files make for good scope boundaries.

On Dec 05, 2015, at 08:40 PM, Ilya via swift-evolution <swift-evolution@swift.org> wrote:

I think the it would help a great deal to have an access level modifier that is really private and visible only inside the class itself. Right now, the only way to hide implementation details for a class is to hide the class code in a separate file, which is very inconvenient for several reasons:

1) the meaning of the code changes depending on which file the class is in. It's very easy to accidentally expose class internal details and then call class elements that are meant to be used only inside the class. Having a keyword for class internals will allow the compiler to ensure that only the public API for the class is used from the outside world. The user can check types on his own, but it's better that the compiler does it automatically. Similarly, the user can check that only the proper APIs are called, but it's better that the compiler does it automatically.

2) accessibility by file structure may cause some really short files.

3) It's impossible to group related classes in one file but still hide implementation details inside each class

I think that it the best solution is to make private keyword do what it states -- keep the class element private to the class. But if it's really important to have a separate keyword for backward compatibility, it would be the next best thing.

--
Ilya Belenkiy

_______________________________________________
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ilya Belenkiy) #4

The number of files Is not the only or the biggest concern. Grouping
related APIs and / or related implementations makes it much easier to keep
everything consistent and easy to find. It's the same benefit as having
multiple paragraphs of text in one file. Only with paragraphs this seems
obvious, but for some reason causes a lot of debate when it comes to code.

···

--
Ilya Belenkiy
On Mon, Dec 14, 2015 at 3:16 PM joe <joe@polka.cat> wrote:

I've only cursorily followed this thread, but with the introduction of the
Swift Package Manager, I'm guessing it will have a role to play in reducing
the number of files one needs to be concerned with at any one time. If one
has such an overwhelming number of files, it's probably likely that they
could be split up into separate packages/modules. I'm not sure how much
that has been considered in regards to worry of ending up with too many
separate files.

And even assuming one runs into cases where there are loads of .swift
files, at least it's still basically half of what there would be in
Objective-C :slight_smile:

> On Dec 14, 2015, at 1:42 PM, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Please take a look at the other posts today. I addressed this concern
earlier. In one sentence, just like you wouldn't want to put every
paragraph of a book or every section of an article in an encyclopedia in a
separate file, you wouldn't want to end up with a gazillion files just to
ensure that implementation details of an API stay hidden in a way that is
enforced by the compiler.
>
> --
> Ilya Belenkiy
>
> On Mon, Dec 14, 2015 at 2:19 PM Colin Cornaby via swift-evolution < > swift-evolution@swift.org> wrote:
> (I'm reading the upstream discussion but I'll reply here.)
>
> I don't know if I really like the pattern this is trying to support. I
like that Swift makes it cleaner to include multiple types in a single
Swift file. But I feel like this proposal is trying to take things too far
the other way. Types that should should only see each other from a non
"friends" role should be in separate files.
>
> What's proposed doesn't really harm someone who likes the "multiple
file" style directly, but I don't want to see projects where everything
gets jammed into one file. I think keeping the scope of private (with no
new keywords) to the same file encourages good coding practices.
>
> I've really liked the balance Swift strikes in this case. I feel like
this discussion is going to come down to opinion, but projects that I've
worked in that have tried to over compact have always run into issues. I
don't know if it's the role of the language to push an ideology either way,
but personally I like the direction Swift is pushing. Files make for good
scope boundaries.
>
> On Dec 05, 2015, at 08:40 PM, Ilya via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> I think the it would help a great deal to have an access level modifier
that is really private and visible only inside the class itself. Right now,
the only way to hide implementation details for a class is to hide the
class code in a separate file, which is very inconvenient for several
reasons:
>>
>> 1) the meaning of the code changes depending on which file the class is
in. It's very easy to accidentally expose class internal details and then
call class elements that are meant to be used only inside the class. Having
a keyword for class internals will allow the compiler to ensure that only
the public API for the class is used from the outside world. The user can
check types on his own, but it's better that the compiler does it
automatically. Similarly, the user can check that only the proper APIs are
called, but it's better that the compiler does it automatically.
>>
>> 2) accessibility by file structure may cause some really short files.
>>
>> 3) It's impossible to group related classes in one file but still hide
implementation details inside each class
>>
>> I think that it the best solution is to make private keyword do what it
states -- keep the class element private to the class. But if it's really
important to have a separate keyword for backward compatibility, it would
be the next best thing.
>>
>> --
>> Ilya Belenkiy
>>
>> _______________________________________________
>> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution