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

[Ilya Belenkiy]

> let/var does actually enforce intent. I have to actually change let to
var before I can modify a value.

"scoped" also enforces intent. You have to actually mark something as at
least "private" to be able to use it outside its scope.

> This proposal does not enforce intent. I do not have to change from
“scoped”/“local” to “private” in > order to break encapsulation - I just
add another method to the class.

Exactly the same is true about "private". You don't have to change from
"private" to "internal" in order to make something accessible from another
file -- you just add another method to the class.

> That is my primary complaint against scoped/local access - it is an
arbitrary limitation that does not > improve my ability to express what is
invariant in a class beyond private. I still have to assume any > change
within a file may have abused scoped access permissions until I evaluate
said change.

Exactly the same is true about "private" vs. "internal". In general, as
long as you have access to the source code, you could move code around or
introduce wrappers to work around the original definition without modifying
it. By this logic, only "internal"  and "public" make sense. And yet,
"private" is in the language because it provides a way to express an intent
related to encapsulation, and that intent is enforced by the compiler.
"scoped" should be there for the same reason.

> My argument, however, is that scoped/local do not meaningfully improve
safety or indicate intent > over a mix of private and partitioning code
into files.

It does. It expresses the intent that a method or a property is private to
the scope in which it is defined. This allows to provide the proper
interface outside of the scope independently of where the scope is in the
source code. This is important because interfaces are defined at the scope
level, not file level. In the most concrete example, this allows hiding
state (data encapsulation), but the same is true for methods in extensions.


On Sat, Feb 27, 2016 at 11:45 AM David Waite <david at alkaline-solutions.com>
wrote:

>
> > On Feb 27, 2016, at 8:57 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > This is a good example of the arguments against the proposal. Let me try
> to summarize and address them:
> >
> > 1) using a convention is sufficient to declare intent
> > 2) the programmer changing the file should know what he is doing, so a
> comment should be enough
> > 3) since the programmer has access to the code, he can just change the
> access level, so there is no need to go beyond the file scope
> > 4) given the previous arguments, this small addition is not worth
> increasing the language complexity
> >
> > Now, let's pretend that "let" is not in the language and run it through
> the list to see if it's worth adding:
> >
> > 1) there is a common convention of using ALL_CAPS for constants (used in
> C). Another common convention is to use "k" in front of the name. Cocoa
> APIs use it in many places. "let" not need. Check.
>
> > 2) if the programmer is expected to have the proper knowledge about the
> file he is in, this is a must for variables / constants in the *local*
> scope. "let" not needed. Check.
> > 3) since the programmer has access to the code, he can always just
> change let to var. The compiler cannot help with that. "Let" doesn't
> protect then, so it's not needed. Check.
> > 4) This definitely increases the language and implementation complexity,
> and especially given (3), it would be an addition that can be easily worked
> around, so why bother? Check.
>
> let/var does actually enforce intent. I have to actually change let to var
> before I can modify a value.
>
> This proposal does not enforce intent. I do not have to change from
> “scoped”/“local” to “private” in order to break encapsulation - I just add
> another method to the class.
>
> That is my primary complaint against scoped/local access - it is an
> arbitrary limitation that does not improve my ability to express what is
> invariant in a class beyond private. I still have to assume any change
> within a file may have abused scoped access permissions until I evaluate
> said change.
>
> Some of my personal opinion on this may be the volume of changes I try to
> evaluate as line-by-line diffs. A change from let to var or from
> non-optional to IUO shows up as part of such a change. Where code was
> lexically inserted within a file does not. Unlike var/let and optionals, I
> don’t believe scoped allows a reviewer to know that invariants were abused
> without an analysis of the file which was modified.
>
> More so, I can request and expect a certain evaluation about a developer
> changing a variable from being constant to non-constant, or from
> non-optional to optional. “Scoped”/“Local” does not require the developer
> to change a line of code to get different behavior - they simply change the
> location where their code is inserted. This is because access control only
> affects behavior at the call site, not the actual functionality of a
> variable or method.
>
> If a developer thinks their method requires access to scoped/local
> properties or methods, they will just add that to the body of the class.
> The *only* thing that makes such a change safe is understanding of the
> invariants of the class - and scoped/local do not affect the behavior of
> these invariants or a developer’s ability/need to understand them
> whatsoever.
>
> My understanding of your argument is that let/var are justified because
> they improve safety and more strongly indicate intent, and that
> scoped/local are justified for the same reason.
>
> My argument, however, is that scoped/local do not meaningfully improve
> safety or indicate intent over a mix of private and partitioning code into
> files. Scoped/local allows the access control model to scale to having more
> code be included in a single file.
>
> -DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/e99461ca/attachment.html>