I am not in favor of this change. While I agree that the implementation of fileprivate and open as well as the changes to private had some unintended by-products, they can easily be accommodated. Sometimes the language by its nature dictates style. I say at this point, we all just need to deal with it and move on. We have bigger and more impactful language features to fry.
IMHO the changes in this proposal create a host of complications in the understanding of what can already be a hard to understand topic. We are greatly increasing the surface area of what must be learned in order to completely grok private and fileprivate. This added complexity does not justify what I feel are just cosmetic improvements to suit a particular coding style.
Changes such as this to suit a particular coding style, need to be avoided or we risk losing focus on the definition and implementation of more critical changes.
I don’t comment on many proposals, but this one stood out as antithetical to the stated goals of the Swift evolution.
Regards, Michael
···
==================
Michael M. Mayer
Hanover, MD
m.mayer6@gmail.com
I am not in favor of this change. While I agree that the implementation of fileprivate and open as well as the changes to private had some unintended by-products, they can easily be accommodated. Sometimes the language by its nature dictates style. I say at this point, we all just need to deal with it and move on. We have bigger and more impactful language features to fry.
IMHO the changes in this proposal create a host of complications in the understanding of what can already be a hard to understand topic. We are greatly increasing the surface area of what must be learned in order to completely grok private and fileprivate.
The goal of progressive disclosure is NOT to reduce the amount of learning you need to get COMPLETE understanding of a topic like access control, but being able to get started easily with a small subset of info and go deeper if you need it and on your terms which this proposal achieves.
···
Sent from my iPhone
On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution <swift-evolution@swift.org> wrote:
This added complexity does not justify what I feel are just cosmetic improvements to suit a particular coding style.
Changes such as this to suit a particular coding style, need to be avoided or we risk losing focus on the definition and implementation of more critical changes.
I don’t comment on many proposals, but this one stood out as antithetical to the stated goals of the Swift evolution.
Regards, Michael
==================
Michael M. Mayer
Hanover, MD
m.mayer6@gmail.com
I am not in favor of this change. While I agree that the implementation of fileprivate and open as well as the changes to private had some unintended by-products, they can easily be accommodated. Sometimes the language by its nature dictates style. I say at this point, we all just need to deal with it and move on. We have bigger and more impactful language features to fry.
IMHO the changes in this proposal create a host of complications in the understanding of what can already be a hard to understand topic. We are greatly increasing the surface area of what must be learned in order to completely grok private and fileprivate.
The goal of progressive disclosure is NOT to reduce the amount of learning you need to get COMPLETE understanding of a topic like access control, but being able to get started easily with a small subset of info and go deeper if you need it and on your terms which this proposal achieves.
Agreed. If this proposal gets accepted, one only needs to learn internal and private to work as an application developer, and only later public and open as a library other. fileprivate can be learned when necessary, in rarer situation.
···
On 11 Apr 2017, at 09:24, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution <swift-evolution@swift.org> wrote:
This added complexity does not justify what I feel are just cosmetic improvements to suit a particular coding style.
Changes such as this to suit a particular coding style, need to be avoided or we risk losing focus on the definition and implementation of more critical changes.
I don’t comment on many proposals, but this one stood out as antithetical to the stated goals of the Swift evolution.
Regards, Michael
==================
Michael M. Mayer
Hanover, MD
m.mayer6@gmail.com