Not only will this reduce bugs but it will also speed up compile times.
Have your read
https://github.com/apple/swift/blob/master/docs/AccessControl.rst?
I prefer the current rationale behind "internal" by default.
Stephen
···
On Mon, Dec 7, 2015 at 11:35 AM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:
Not only will this reduce bugs but it will also speed up compile times.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
+1 to this from the point of view of correctness. But it's important to
realize the drawback in the language "friendliness".
Other defaults that I think could be reconsidered along these lines: final
by default for classes and final by default for methods.
···
On Mon, Dec 7, 2015 at 8:35 AM Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:
Not only will this reduce bugs but it will also speed up compile times.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto
Let's start a separate thread for "final-by-default". It's definitely worth discussing. This thread can continue discussing "private-by-default".
Jordan
···
On Dec 7, 2015, at 10:48, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
+1 to this from the point of view of correctness. But it's important to realize the drawback in the language "friendliness".
Other defaults that I think could be reconsidered along these lines: final by default for classes and final by default for methods.+1 to final on classes and class members being the default. I have wished this was the case ever since Swift was released. It is not uncommon to have a need for a reference type without a need for inheritance. Superclasses should be intentionally designed to be subclasses and the author required to opt-in to subclassing and member overrides where that is required by the design.
Have your read https://github.com/apple/swift/blob/master/docs/AccessControl.rst?
I prefer the current rationale behind "internal" by default.
Stephen
I must admit that I make as many things private as possible so that I can have the faster incremental compiles.
···
On Dec 7, 2015, at 11:46 AM, Stephen Celis <stephen.celis@gmail.com> wrote:
On Mon, Dec 7, 2015 at 11:35 AM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Not only will this reduce bugs but it will also speed up compile times.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
+1 to this from the point of view of correctness. But it's important to realize the drawback in the language "friendliness".
Other defaults that I think could be reconsidered along these lines: final by default for classes and final by default for methods.
+1 to final on classes and class members being the default. I have wished this was the case ever since Swift was released. It is not uncommon to have a need for a reference type without a need for inheritance. Superclasses should be intentionally designed to be subclasses and the author required to opt-in to subclassing and member overrides where that is required by the design.
I'm less sure about private being the default but willing to consider arguments for it. I also think any change to default access control should be considered in conjunction with any other modifications to access control such as the 'classified' proposal.
I'd be interested in a proposal around classes/methods being final by
default. Not sure where things would end up with "friendliness", though.
Stephen
···
On Mon, Dec 7, 2015 at 1:11 PM, Javier Soto via swift-evolution < swift-evolution@swift.org> wrote:
+1 to this from the point of view of correctness. But it's important to
realize the drawback in the language "friendliness".
Other defaults that I think could be reconsidered along these lines: final
by default for classes and final by default for methods.On Mon, Dec 7, 2015 at 8:35 AM Amir Michail via swift-evolution < > swift-evolution@swift.org> wrote:
Not only will this reduce bugs but it will also speed up compile times.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I think internal as default is bad, because it discourages encapsulation.
Building scalable software components relies on hiding implementation details to create layers of abstraction. It’s a fundamental principle of object-oriented software design. Most other OOP languages have private default.
The linked doc doesn’t explain the advantages of internal as default in detail:
By default, most entities in a source file have internal access. This optimizes for the most common case—a single-target
application project—while not accidentally revealing entities to clients of a framework module.
Optimizes for what? Build time? Brevity?
Knut
···
Have your read
https://github.com/apple/swift/blob/master/docs/AccessControl.rst?I prefer the current rationale behind "internal" by default.
Stephen
If you group these methods in a `private extension`, they'll be private by
default, which seems to be a nice alternative to me.
Stephen
···
On Mon, Dec 7, 2015 at 11:49 AM, Amir Michail <a.michail@me.com> wrote:
On Dec 7, 2015, at 11:46 AM, Stephen Celis <stephen.celis@gmail.com> > wrote:
Have your read
https://github.com/apple/swift/blob/master/docs/AccessControl.rst?I prefer the current rationale behind "internal" by default.
Stephen
I must admit that I make as many things private as possible so that I can
have the faster incremental compiles.On Mon, Dec 7, 2015 at 11:35 AM, Amir Michail via swift-evolution < > swift-evolution@swift.org> wrote:
Not only will this reduce bugs but it will also speed up compile times.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I think internal as default is bad, because it discourages encapsulation.
Building scalable software components relies on hiding implementation details to create layers of abstraction. It’s a fundamental principle of object-oriented software design. Most other OOP languages have private default.
That is not at all true. The dynamic OOP languages do not, as a rule, have any access control at all. Java and C# default to package access, which is analogous to internal. C++ is, as always, complicated and different.
The linked doc doesn’t explain the advantages of internal as default in detail:
By default, most entities in a source file have internal access. This optimizes for the most common case—a single-target
application project—while not accidentally revealing entities to clients of a framework module.Optimizes for what? Build time? Brevity?
Convenience. Programs are free to completely ignore access control if they want. That's also pretty good for teachability.
Access control matters most for people organizing their code into libraries. Ultimately, we expect libraries to be packaged as independent modules (that can still be built directly into your application without dynamic cost, of course). An internal declaration is private to the module, and so the default rule still provides encapsulation by default at the library boundary. But not all code is library code, and we don't want to burden application development with having to specify access control everywhere.
John.
···
On May 15, 2016, at 12:15 PM, Knut Lorenzen via swift-evolution <swift-evolution@swift.org> wrote:
Knut
Have your read
https://github.com/apple/swift/blob/master/docs/AccessControl.rst?I prefer the current rationale behind "internal" by default.
Stephen
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
If you group these methods in a `private extension`, they'll be private by default, which seems to be a nice alternative to me.
I wouldn’t want to reorder methods like that.
Swift compiles take up a lot of energy and I suspect people programming on MacBooks would like to make incremental compiles as efficient as possible to make their batteries last longer.
···
On Dec 7, 2015, at 11:52 AM, Stephen Celis <stephen.celis@gmail.com> wrote:
Stephen
On Mon, Dec 7, 2015 at 11:49 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
On Dec 7, 2015, at 11:46 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
Have your read https://github.com/apple/swift/blob/master/docs/AccessControl.rst?
I prefer the current rationale behind "internal" by default.
Stephen
I must admit that I make as many things private as possible so that I can have the faster incremental compiles.
On Mon, Dec 7, 2015 at 11:35 AM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Not only will this reduce bugs but it will also speed up compile times.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
That is not at all true. The dynamic OOP languages do not, as a rule, have any access control at all. Java and C# default to package access, which is analogous to internal. C++ is, as always, complicated and different.
Class members are private by default in both Java and C#. As are ivars and selectors in Objective-C (the latter having to be redeclared in the header file for module-wide access). Swift definitely gives greater default scope to class members in comparison to other OOP languages.
Convenience. Programs are free to completely ignore access control if they want.
Convenience can also be lead to shortsightedness and poor code structure. Programmers will be tempted to modify a property or call a function from anywhere just because can, instead of thinking twice because they need mark it as internal first.
And when reading someone else's code, it is hard to tell the scope of properties and functions if they are internal by default. One has to tediously examine them one by one for project-wide use.
That's also pretty good for teachability.
How so? I think especially beginners need to learn the importance of encapsulation. Hiding implementation details in order to create layers of abstraction is a fundamental concept of software design.
and so the default rule still provides encapsulation by default at the library boundary. But not all code is library code, and we don't want to burden application development with having to specify access control everywhere.
Following that rationale, why does private even exist? Seems inconsistent
Knut
···
On 19 May 2016, at 19:18, John McCall <rjmccall@apple.com> wrote:
That is not at all true. The dynamic OOP languages do not, as a rule, have any access control at all. Java and C# default to package access, which is analogous to internal. C++ is, as always, complicated and different.
Class members are private by default in both Java and C#. As are ivars and selectors in Objective-C (the latter having to be redeclared in the header file for module-wide access). Swift definitely gives greater default scope to class members in comparison to other OOP languages.
On Java, they are package-private, not private by default, which is closer to module visibility of swift than private.
···
Le 23 mai 2016 à 23:21, Knut Lorenzen via swift-evolution <swift-evolution@swift.org> a écrit :
On 19 May 2016, at 19:18, John McCall <rjmccall@apple.com> wrote:
Knut
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I was just about to mention this too. I think it's interesting that
one can write a simple application in Swift without having to worry
(much) about visibility of elements. Please note I'm talking about
applications not frameworks.
I'm glad this is working for you, because this is exactly the intent.
I also agree this is good for teachability because you can worry about
more important aspects of programming (functionality and structure)
than just the correct visibility (that makes no difference to a
student until they move to coding a framework themselves).
Right. I think the phrase Chris likes to pull out here is "progressive disclosure":
the language should allow you to focus on learning one lesson at a time.
Making students write "public" everywhere doesn't make understand good
code structure and encapsulation; it just forces them to learn a magic word.
In fact — and here I'll confess to not being up-to-date on CS pedagogy
research, and if I'm mistaken I would be happy to be corrected — intuitively I find
it improbable that you can really teach encapsulation to intro students at all.
I mean, sure, you can teach the terminology and mechanics, and you can
mandate a particular code style for their assignments, but they won't really
understand the value until they've experienced the problems of code that
*isn't* well-abstracted.
But I also agree that, to some extent, private may not make sense if
the default visibility is already not visible outside the current
module but should that be an excuse to just drop it?
It makes sense for programmers to be able to develop strong abstractions
within a module. We're not going to drop private.
John.
···
On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
I was just about to mention this too. I think it's interesting that
one can write a simple application in Swift without having to worry
(much) about visibility of elements. Please note I'm talking about
applications not frameworks.
I also agree this is good for teachability because you can worry about
more important aspects of programming (functionality and structure)
than just the correct visibility (that makes no difference to a
student until they move to coding a framework themselves). I
understand Knut's point in clarity but that's the same with the
languages mentioned and many more: one visibility is the default in
each language and as developers we have to understand and know that
for our language of choice and we shouldn't be required anything more
explicit than that (you're not required in Java to declare defaults).
But I also agree that, to some extent, private may not make sense if
the default visibility is already not visible outside the current
module but should that be an excuse to just drop it? I, on the other
hand, miss the protected visibility but I understand it's lack
conforms to the programming model proposed for the language (I know I
should use delegates instead of it).
So, in my opinion, if anything is to be changed regarding visibility
it would be to drop the private visibility at all but not change the
default visibility to private because only what is visible outside
(public) is what matters to be declared, right?
···
On 23 May 2016 at 18:45, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> wrote:
Le 23 mai 2016 à 23:21, Knut Lorenzen via swift-evolution <swift-evolution@swift.org> a écrit :
On 19 May 2016, at 19:18, John McCall <rjmccall@apple.com> wrote:
That is not at all true. The dynamic OOP languages do not, as a rule, have any access control at all. Java and C# default to package access, which is analogous to internal. C++ is, as always, complicated and different.
Class members are private by default in both Java and C#. As are ivars and selectors in Objective-C (the latter having to be redeclared in the header file for module-wide access). Swift definitely gives greater default scope to class members in comparison to other OOP languages.
On Java, they are package-private, not private by default, which is closer to module visibility of swift than private.
Knut
_______________________________________________
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
I was just about to mention this too. I think it's interesting that
one can write a simple application in Swift without having to worry
(much) about visibility of elements. Please note I'm talking about
applications not frameworks.I'm glad this is working for you, because this is exactly the intent.
I also agree this is good for teachability because you can worry about
more important aspects of programming (functionality and structure)
than just the correct visibility (that makes no difference to a
student until they move to coding a framework themselves).Right. I think the phrase Chris likes to pull out here is "progressive disclosure":
the language should allow you to focus on learning one lesson at a time.
Making students write "public" everywhere doesn't make understand good
code structure and encapsulation; it just forces them to learn a magic word.In fact — and here I'll confess to not being up-to-date on CS pedagogy
research, and if I'm mistaken I would be happy to be corrected — intuitively I find
it improbable that you can really teach encapsulation to intro students at all.
I mean, sure, you can teach the terminology and mechanics, and you can
mandate a particular code style for their assignments, but they won't really
understand the value until they've experienced the problems of code that
*isn't* well-abstracted.
+1 share the view. Over the years I have seen a lot of IMHO poorly abstracted code that on the outside was following the view that if "if it is inside, then it is good OO". Teaching encapsulation is hard, and I do join the chorus saying that the problem starts was initializers (I do *pray* that swift does not give in to the partial-inits/auto-inits proposals I've seen floating). I understand more and more, in my day to day professional life, why people would look to FP for a solution: the mount of damages contained in an bad method at least has a clear boundary.
···
On May 24, 2016, at 4:23 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
But I also agree that, to some extent, private may not make sense if
the default visibility is already not visible outside the current
module but should that be an excuse to just drop it?It makes sense for programmers to be able to develop strong abstractions
within a module. We're not going to drop private.John.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution