Hi Xiaodi,
that currently all members of a class or struct are exposed by default by having
a default scope of ‘internal’ and are therefore accessible in the entire module
is imho very bad unstructured programming practice.
In no other OOP language it is implemented
that way..
from this Swift blog:
Access Control - Swift Blog - Apple Developer <Access Control - Swift Blog - Apple Developer;
i quote from this blog:
"By default, all entities have internal access.
This allows application developers to largely ignore access control,
and most Swift code already written will continue to work without change."
Whoever wrote this, imho it is bad: especially this part:
"This allows application developers to largely ignore access control”
To say the least, this not really a very well thought over sentence,
which appears to me something like:
“Hey yeah, it’s ok, just start coding like a blind horse,
don’t worry about the details now. Care about it later. ”
This is certainly not my idea of what is described as “Progressive Disclosure”
and encourages bad and unstructured programming. Students learn
undesirable habits which, as with any habit, are hard to get rid off and
can carry on throughout a large part of their career.
So, in this perspective, what is related to “Progressive Disclosure” should
be viewed with a grain of salt and due to the complexity of Swift its relevancy
is limited and should be approached with caution.
True, in Swift , one can write in a very simple way, but this apparent triviality is
deceiving... To make professional applications with Swift (or for that
matter in any other serious programming language ) one should only
start making real apps equipped with a thorough understanding of the overall
language structure, its philosophy and environment, rather sooner than later.
That ’s exactly where tutorials, courses, books, playgrounds etc. are meant for!
There is a lot of very good material available, so there is really no obstacle
to learn these fundamentals of the Swift language quite well before embarking
on creating professional Swift apps.
Of course, one cannot (should not) define anything at all without knowing
about scope, access modifiers! Luckily, compared to other aspects of PLs,
understanding scope of variables is almost trivial. Provided of course that
the scope mechanism is natural and orthogonal, unfortunately this is
not the case in Swift,.
Also in Swift there should be lexical scope only, I think, as in almost any other
procedural / OOP programming language. Swift is one of them.
This also eliminates the necessity of the keywords “private” and “fileprivate”
and makes the scope context easy to conceive , especially for
beginning programmers.
But it seems to be too late now to correct this deficiency (imho) in Swift I guess..
Concerning your *struct* example:
with correct lexical scope, it should then be written like this:
struct PointOfView
{
public let x: Int // or any other applicable access modifier
public let y: Int
public func distanceToPoint( p: PointOfView) -> Double {. . .}
let pr: Int // private by default, not available outside this struct.
func Foo() { . . .} // private function
}
As written before, for a class, one can add
‘protected’ items like so:
protected var foo:Double // available to descendants (subclasses)
Kind Regards from a sunny www.speyer.de
TedvG
www.tedvg.com
···
On 4. Apr 2017, at 01:44, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
The default access level is internal by default, not public. While there are good reasons to not make members public by default, it is important that members are internal by default.
One important reason: progressive disclosure. Access modifiers make sense after you understand what encapsulation is all about. Encapsulation only really makes sense after you can actually write a type. If members are private by default, you cannot write a useful type without also learning access modifiers!
Put another way:
struct Point {
let x: Int
let y: Int
}
...is by itself a useful type. If x and y were private, then this type would do nothing. Users would have to learn about access modifiers before they can write a useful type.
On Mon, Apr 3, 2017 at 18:13 Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello,
(this is related to: Type-based ‘private’ access within a file)
Currently class and struct items (variables, functions..) are public by default
that is, always accessible outside the class’s scope
for example: (Swift 3.1)
class AsItIsNow
{
private var a = 10
private var b = 12
func aPlusB() -> Int
{
return a + b
}
private func helperFunction()
{
. . .
}
}
Having all items public by default has the following disadvantages:
• All members are exposed by default, wether intended or not. This
could lead to class misusage unintended by the class’s creator.
• To prevent undesired access of functions vars etc. inside a class
one has to prefix often too many items with the ‘private’ access modifier keyword.
Most of the functionality and items inside a class or struct are meant to
be used internally and should not be revealed to the outside world.
• It does not comply (contradicts) with lexical scope as in Swift functions etc.
• It is frontally different to most other programming languages and
therefore confusing for those coming from C#, C++, Java, Pascal etc.
I experience this as fundamentally wrong.
Imho it should be as in the next example, everything in a class
is private by default. To access/deploy items from outside they
need to be defined with the ‘public’ access modifier,
not the other way around, please.
class AsItShouldBeImho
{
var a = 10 // private by default
var b = 12 // also
public func aPlusB() -> Int
{
return a + b
}
func privateFunction()
{
. . .
}
}
‘public’ could be an inferred attribute
for items defined with getters and setters..
or the compiler would demand public
for getters and setters..
The ‘protected’ keyword is needed.
‘protected’ would mean that the items are
accessible in subclasses (class only)
private items would also be inaccessible in
class extensions.
It is as yet unclear to me why it has not been done
like so from the beginning of Swift…
I’ve been lost in the eternal discussions over private access modifiers,
the volume of it makes me think that (either way in this discussions) the whole
scope definition is wrong in Swift .
especially using a file as scope limiter.
Imho there should be lexical scope only.
as in most other programming languages.
If done so correctly , one wouldn’t even need the ‘private’ keyword...
Kind Regards
TedvG
www.tedvg.com <http://www.tedvg.com/>
www.ravelnotes.com <http://www.ravelnotes.com/>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution