access control proposal

Colin_Cornaby · December 14, 2015, 9:11pm

I don't think this analogy follows. Books have division lines of pages or chapters that compartmentalize information. In the same way, development projects traditionally have a separation of concerns that are organized using different source code files. I don't know if a "gazillion" accurately captures the number of files required to separate concerns. On the other hand, I'm also not sure if Swift should try to enforce good development practices as policy (but I like the practice it's trying to support here.)

I'm just watching this from the sidelines, but I haven't seen a compelling example case anywhere in the discussion that would lead to just an unmaintanable number of files. Even for multiple teams all working on the same source... separation of files seems like the cleanest solution.

As others have mentioned, iOS and Mac development (as well as open source Swift) seems to be going in the direction of a single application or project containing multiple modules. Mac has been doing that with great success for a long time. Given that's the direction things are going, private as it exists now even seems a little heavy for a lot of uses. It's completely realistic the projects are going to start separating concerns over module boundaries and not just source file boundaries. This proposal just seems to be going the opposite way that Swift and Apple platform development is going.

Files are easy to understand, and they're lightweight, and I just haven't been convinced that files with small amount of source are even a bad thing, nor have I seen Swift projects out in the wild that have too many short Swift source files that is a result of language restrictions. Do you have any examples of projects out in the community?

···

On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> 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

Ilya_Belenkiy · December 15, 2015, 12:10pm

This is a matter of opinion. I think that the proposal is very much in line
with Swift's emphasis on strong types and protocols and adds clarity about
where an API can be used.

···

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby@mac.com> wrote:

I don't think this analogy follows. Books have division lines of pages or
chapters that compartmentalize information. In the same way, development
projects traditionally have a separation of concerns that are organized
using different source code files. I don't know if a "gazillion" accurately
captures the number of files required to separate concerns. On the other
hand, I'm also not sure if Swift should try to enforce good development
practices as policy (but I like the practice it's trying to support here.)

I'm just watching this from the sidelines, but I haven't seen a compelling
example case anywhere in the discussion that would lead to just an
unmaintanable number of files. Even for multiple teams all working on the
same source... separation of files seems like the cleanest solution.

As others have mentioned, iOS and Mac development (as well as open source
Swift) seems to be going in the direction of a single application or
project containing multiple modules. Mac has been doing that with great
success for a long time. Given that's the direction things are going,
private as it exists now even seems a little heavy for a lot of uses. It's
completely realistic the projects are going to start separating concerns
over module boundaries and not just source file boundaries. This proposal
just seems to be going the opposite way that Swift and Apple platform
development is going.

Files are easy to understand, and they're lightweight, and I just haven't
been convinced that files with small amount of source are even a bad thing,
nor have I seen Swift projects out in the wild that have too many short
Swift source files that is a result of language restrictions. Do you have
any examples of projects out in the community?

On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> > 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

Colin_Cornaby · December 15, 2015, 4:35pm

I guess where I get skeptical is the example case. In this example, a module that should otherwise be simple but is made complicated by having too many source files in Swift is really a module that should be simple, but has been made complicated by too many custom types. If we’re talking about a simple module that has been overcomplicated by too many types (Swift scoping aside), we’re talking about a module that likely has significant architectural problems. That’s why I asked if there were any examples. I was wondering if there were any cases where a project’s design was otherwise sound, but maintainability was compromised by a lack of fine grain scoping in Swift. What’s been talked about so far seems to really be Swift source that is suffering from design issues or overbuilding, and instead of fixing those design issues that’s leading to a large number of source files, we’re talking about paving over those design issues with new language constraints.

I don’t know where the Swift team falls in having Swift as a language that supports questionable development practices. But to me, I’m still just not convinced the work to change this would be justified by any real gain in good development practices.

···

On Dec 15, 2015, at 4:10 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> wrote:

This is a matter of opinion. I think that the proposal is very much in line with Swift's emphasis on strong types and protocols and adds clarity about where an API can be used.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby@mac.com <mailto:colin.cornaby@mac.com>> wrote:
I don't think this analogy follows. Books have division lines of pages or chapters that compartmentalize information. In the same way, development projects traditionally have a separation of concerns that are organized using different source code files. I don't know if a "gazillion" accurately captures the number of files required to separate concerns. On the other hand, I'm also not sure if Swift should try to enforce good development practices as policy (but I like the practice it's trying to support here.)

I'm just watching this from the sidelines, but I haven't seen a compelling example case anywhere in the discussion that would lead to just an unmaintanable number of files. Even for multiple teams all working on the same source... separation of files seems like the cleanest solution.

As others have mentioned, iOS and Mac development (as well as open source Swift) seems to be going in the direction of a single application or project containing multiple modules. Mac has been doing that with great success for a long time. Given that's the direction things are going, private as it exists now even seems a little heavy for a lot of uses. It's completely realistic the projects are going to start separating concerns over module boundaries and not just source file boundaries. This proposal just seems to be going the opposite way that Swift and Apple platform development is going.

Files are easy to understand, and they're lightweight, and I just haven't been convinced that files with small amount of source are even a bad thing, nor have I seen Swift projects out in the wild that have too many short Swift source files that is a result of language restrictions. Do you have any examples of projects out in the community?

On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com <mailto:ilya.belenkiy@gmail.com>> 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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

anandabits · December 15, 2015, 4:41pm

So the takeaway from this, which I think is a good point, is that any proposal needs to have some concrete motivating examples that are otherwise well designed and where a reasonable argument can be made that they benefit from this. This is something all proposals should have. Not everyone will agree about the degree of benefit and how it relates to the feature, but a concrete example will provide focus for that discussion.

Matthew

···

On Dec 15, 2015, at 10:35 AM, Colin Cornaby via swift-evolution <swift-evolution@swift.org> wrote:

I guess where I get skeptical is the example case. In this example, a module that should otherwise be simple but is made complicated by having too many source files in Swift is really a module that should be simple, but has been made complicated by too many custom types. If we’re talking about a simple module that has been overcomplicated by too many types (Swift scoping aside), we’re talking about a module that likely has significant architectural problems. That’s why I asked if there were any examples. I was wondering if there were any cases where a project’s design was otherwise sound, but maintainability was compromised by a lack of fine grain scoping in Swift. What’s been talked about so far seems to really be Swift source that is suffering from design issues or overbuilding, and instead of fixing those design issues that’s leading to a large number of source files, we’re talking about paving over those design issues with new language constraints.

I don’t know where the Swift team falls in having Swift as a language that supports questionable development practices. But to me, I’m still just not convinced the work to change this would be justified by any real gain in good development practices.

On Dec 15, 2015, at 4:10 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com <mailto:ilya.belenkiy@gmail.com>> wrote:

This is a matter of opinion. I think that the proposal is very much in line with Swift's emphasis on strong types and protocols and adds clarity about where an API can be used.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby@mac.com <mailto:colin.cornaby@mac.com>> wrote:
I don't think this analogy follows. Books have division lines of pages or chapters that compartmentalize information. In the same way, development projects traditionally have a separation of concerns that are organized using different source code files. I don't know if a "gazillion" accurately captures the number of files required to separate concerns. On the other hand, I'm also not sure if Swift should try to enforce good development practices as policy (but I like the practice it's trying to support here.)

I'm just watching this from the sidelines, but I haven't seen a compelling example case anywhere in the discussion that would lead to just an unmaintanable number of files. Even for multiple teams all working on the same source... separation of files seems like the cleanest solution.

As others have mentioned, iOS and Mac development (as well as open source Swift) seems to be going in the direction of a single application or project containing multiple modules. Mac has been doing that with great success for a long time. Given that's the direction things are going, private as it exists now even seems a little heavy for a lot of uses. It's completely realistic the projects are going to start separating concerns over module boundaries and not just source file boundaries. This proposal just seems to be going the opposite way that Swift and Apple platform development is going.

Files are easy to understand, and they're lightweight, and I just haven't been convinced that files with small amount of source are even a bad thing, nor have I seen Swift projects out in the wild that have too many short Swift source files that is a result of language restrictions. Do you have any examples of projects out in the community?

On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com <mailto:ilya.belenkiy@gmail.com>> 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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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 · December 15, 2015, 4:49pm

There are a lot of unreasonable assumptions here. That's all I have to say
in response.

···

--
Ilya Belenkiy

On Tue, Dec 15, 2015 at 11:35 AM Colin Cornaby <colin.cornaby@mac.com> wrote:

I guess where I get skeptical is the example case. In this example, a
module that should otherwise be simple but is made complicated by having
too many source files in Swift is really a module that should be simple,
but has been made complicated by too many custom types. If we’re talking
about a simple module that has been overcomplicated by too many types
(Swift scoping aside), we’re talking about a module that likely has
significant architectural problems. That’s why I asked if there were any
examples. I was wondering if there were any cases where a project’s design
was otherwise sound, but maintainability was compromised by a lack of fine
grain scoping in Swift. What’s been talked about so far seems to really be
Swift source that is suffering from design issues or overbuilding, and
instead of fixing those design issues that’s leading to a large number of
source files, we’re talking about paving over those design issues with new
language constraints.

I don’t know where the Swift team falls in having Swift as a language that
supports questionable development practices. But to me, I’m still just not
convinced the work to change this would be justified by any real gain in
good development practices.

On Dec 15, 2015, at 4:10 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> > wrote:

This is a matter of opinion. I think that the proposal is very much in
line with Swift's emphasis on strong types and protocols and adds clarity
about where an API can be used.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby@mac.com> > wrote:

I don't think this analogy follows. Books have division lines of pages or
chapters that compartmentalize information. In the same way, development
projects traditionally have a separation of concerns that are organized
using different source code files. I don't know if a "gazillion" accurately
captures the number of files required to separate concerns. On the other
hand, I'm also not sure if Swift should try to enforce good development
practices as policy (but I like the practice it's trying to support here.)

I'm just watching this from the sidelines, but I haven't seen a
compelling example case anywhere in the discussion that would lead to just
an unmaintanable number of files. Even for multiple teams all working on
the same source... separation of files seems like the cleanest solution.

As others have mentioned, iOS and Mac development (as well as open source
Swift) seems to be going in the direction of a single application or
project containing multiple modules. Mac has been doing that with great
success for a long time. Given that's the direction things are going,
private as it exists now even seems a little heavy for a lot of uses. It's
completely realistic the projects are going to start separating concerns
over module boundaries and not just source file boundaries. This proposal
just seems to be going the opposite way that Swift and Apple platform
development is going.

Files are easy to understand, and they're lightweight, and I just haven't
been convinced that files with small amount of source are even a bad thing,
nor have I seen Swift projects out in the wild that have too many short
Swift source files that is a result of language restrictions. Do you have
any examples of projects out in the community?

On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> >> 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

Ilya_Belenkiy · December 15, 2015, 5:17pm

I think that I already gave simple and reasonable examples. If this was a
complicated issue, I would agree that a coded example would be useful. But
in this case, it looks like anything small will be called contrived, and
anything big will be called poorly designed.

I think that I already presented my case. I hope that the discussion is
enough to submit a formal proposal. If not, I'll stop here.

···

--
Ilya Belenkiy

On Tue, Dec 15, 2015 at 11:41 AM Matthew Johnson <matthew@anandabits.com> wrote:

So the takeaway from this, which I think is a good point, is that any
proposal needs to have some concrete motivating examples that are otherwise
well designed and where a reasonable argument can be made that they benefit
from this. This is something all proposals should have. Not everyone will
agree about the degree of benefit and how it relates to the feature, but a
concrete example will provide focus for that discussion.

Matthew

On Dec 15, 2015, at 10:35 AM, Colin Cornaby via swift-evolution < > swift-evolution@swift.org> wrote:

I guess where I get skeptical is the example case. In this example, a
module that should otherwise be simple but is made complicated by having
too many source files in Swift is really a module that should be simple,
but has been made complicated by too many custom types. If we’re talking
about a simple module that has been overcomplicated by too many types
(Swift scoping aside), we’re talking about a module that likely has
significant architectural problems. That’s why I asked if there were any
examples. I was wondering if there were any cases where a project’s design
was otherwise sound, but maintainability was compromised by a lack of fine
grain scoping in Swift. What’s been talked about so far seems to really be
Swift source that is suffering from design issues or overbuilding, and
instead of fixing those design issues that’s leading to a large number of
source files, we’re talking about paving over those design issues with new
language constraints.

I don’t know where the Swift team falls in having Swift as a language that
supports questionable development practices. But to me, I’m still just not
convinced the work to change this would be justified by any real gain in
good development practices.

On Dec 15, 2015, at 4:10 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> > wrote:

This is a matter of opinion. I think that the proposal is very much in
line with Swift's emphasis on strong types and protocols and adds clarity
about where an API can be used.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 4:11 PM Colin Cornaby <colin.cornaby@mac.com> > wrote:

I don't think this analogy follows. Books have division lines of pages or
chapters that compartmentalize information. In the same way, development
projects traditionally have a separation of concerns that are organized
using different source code files. I don't know if a "gazillion" accurately
captures the number of files required to separate concerns. On the other
hand, I'm also not sure if Swift should try to enforce good development
practices as policy (but I like the practice it's trying to support here.)

I'm just watching this from the sidelines, but I haven't seen a
compelling example case anywhere in the discussion that would lead to just
an unmaintanable number of files. Even for multiple teams all working on
the same source... separation of files seems like the cleanest solution.

As others have mentioned, iOS and Mac development (as well as open source
Swift) seems to be going in the direction of a single application or
project containing multiple modules. Mac has been doing that with great
success for a long time. Given that's the direction things are going,
private as it exists now even seems a little heavy for a lot of uses. It's
completely realistic the projects are going to start separating concerns
over module boundaries and not just source file boundaries. This proposal
just seems to be going the opposite way that Swift and Apple platform
development is going.

Files are easy to understand, and they're lightweight, and I just haven't
been convinced that files with small amount of source are even a bad thing,
nor have I seen Swift projects out in the wild that have too many short
Swift source files that is a result of language restrictions. Do you have
any examples of projects out in the community?

On Dec 14, 2015, at 11:42 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> >> 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

owensd · December 15, 2015, 5:37pm

There’s no reason to not submit a proposal for it with examples and references to the criticism in this thread and your counter for it. If nothing else, it would consolidate this thread as there have been multiple variations proposed throughout and solidify exactly what the proposal is all about.

My person vote is to not support further grain access controls. It's not because your examples were not reasonable, but because I come from a perspective where I don’t think the language complexity warrants it and the use case is very narrowly focused. Others have been in favor of it though.

So go for it.

-David

···

On Dec 15, 2015, at 9:17 AM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

I think that I already gave simple and reasonable examples. If this was a complicated issue, I would agree that a coded example would be useful. But in this case, it looks like anything small will be called contrived, and anything big will be called poorly designed.

I think that I already presented my case. I hope that the discussion is enough to submit a formal proposal. If not, I'll stop here.