[swift-evolution] [Review] SE-0025 Scoped Access Level

[Ilya Belenkiy]

If the primary goal is to keep the language small, this would be a good
argument for removing "private". But if the goal is clarity and
correctness, then "scoped" will help with both. There are many constructs
in the language already that are not strictly necessary and can be
expressed via other means. For example, anything that you can do with
"guard", you can do with "if". But they are there because they help clarity
and correctness. "scoped" is like that.

On Sat, Feb 27, 2016 at 3:00 PM Taras Zakharko via swift-evolution <
swift-evolution at swift.org> wrote:

>
>    - What is your evaluation of the proposal?
>
> I am agains it. My rationale below.
>
> One of Ilya’s main points is that encapsulation is a core principle of OOP
> and that Swift lacks tools to implement this properly. I think the
> terminology is somehow unlucky here. Encapsulation more universally refers
> to bundling of data and code that operates of that data, and this is indeed
> one of the things that defines OOP as a programming style. However, it
> seems that Ilya refers to data hiding, which often accompanies
> encapsulation. I believe it is important to distinguish these two concepts.
> Encapsulation as I use here is a particular problem-solving style while
> data hiding (what Ilya stresses) is a technique for enforcing program
> correctness. It is also not true that data hiding is a fundamental
> component of OOP languages, some of the popular ones don’t have any data
> hiding (e.g. Python).
>
> Data hiding obviously has an important core function, which is, as I
> mentioned above — making sure that the program is correct, by only exposing
> the interface other components should have safe access to. Swift has data
> hiding, only the philosophy of that data hiding is a bit different from the
> mainstream implementations. The scope of the most restricted access is the
> file. If I understand the background of this design decision correctly,
> goal here is to allow the programmer to be as flexible as possible about
> what can access what but also to ‘force' them to think about their code
> design and code layout (by organising interrelated stuff by files). Is this
> an ideal decision to the problem? Certainly not — it imposes some
> inconveniences on the programmer and can also compromise code safety (as
> Illya points out). Is this a good, elegant decision? In my opinion, yes.
>
> I can also understand Illya’s point that a local scope access might
> improve code safety in certain cases. What I disagree with is that these
> cases are prominent or problematic enough to deserve such attention. Adding
> new access modifiers makes the rules of the language more complicated, but
> I seriously doubt that a ‘local’ specifier will make programmers
> significantly more productive or prevent any number of serious bugs. So
> far, arguments presented were more of the ideological nature and while they
> are formally correct, I do not think that the actual end effect is as
> dramatic as described. In addition, I would like to point out that ‘local’
> is also only an approximation — it does not solve the safety problem
> entirely. It merely functions as an additional safeguard agains programmer
> error. The actual problem can be only solved by specifying full rules what
> is accessible from where and under which conditions. A system like that
> probably won’t be practical enough for everyday programming at this point.
>
> I also think that the comparison with ‘let/var’ as brough try Ilya is
> flawed — variable mutability concerns the basic design of the data
> structure/algorithm itself, while data hiding concerns the fragility of a
> data structure. I understand that the boundary between these two is very
> fluent, as one can portray fragility as design by encapsulating/hiding
> parts of the implementation. However, we are talking about actual
> implementations (e.g. variables, code etc. that the implementation use)
> rather then the abstract structure of implementations.
>
> To sum it up: Swift already supports an elegant data hiding mechanism
> which IMO solves the biggest issue: components are already shielded agains
> incorrect EXTERNAL use. It remains prone to incorrect use in the same file.
> As far as I am concerned, the practical consequences of this are
> negligible. I have some experience with languages that do not have any data
> hiding whatsoever and I can’t say that I ever had any issues with messing
> up the private and public interfaces — neither in my own code nor in code
> written in collaboration with other people. In this regards  do not believe
> that ‘local’ will add anything of value to the language, however it will
> make the rules more complicated.
>
>
>    - Is the problem being addressed significant enough to warrant a
>    change to Swift?
>
>
>    - Does this proposal fit well with the feel and direction of Swift?
>
> I do not know. The problem of code safety is a fundamental one, but I am
> not sure that Swift has ever had the ambition to solve all of them. For me,
> the offered solution is good enough.
>
>
>    - If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
>    - How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> I have read the proposal, and participated in the original discussion. I
> can’t claim to have performed an in-depth study though.
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug Gregor
>
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/9bf06b56/attachment.html>