On 17.02.2017 20:16, David Sweeris via swift-evolution wrote:
Sent from my iPhone
On Feb 17, 2017, at 01:02, Rien <[email protected]> wrote:
On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution
<[email protected]> wrote:
On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution
<[email protected]> wrote:
While we’re bikeshedding, I’m going to add my two cents. Hold on
to your hat because this might be controversial here.
I think both ‘private’ and ‘fileprivate’ are unnecessary
complications that only serve to clutter the language.
It would make a lot more sense to just have internal and public
only. No private, no fileprivate, no lineprivate, no protected.
It’s all silly.
Eh, I've used `private` to keep myself honest in terms of going
through some book-keeping functions instead of directly accessing a
property.
But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
With great power there comes great responsibility ;-)
I don't see how... I used `private` on some dicts that interact with
each other (faking a lightweight database) to ensure I was using my
type's subscript functions (which handle updating all the dicts
correctly) instead of directly accessing the dictionaries in some areas
where the interactions theoretically wouldn't matter. Since I was able
to mark those properties as private, I know that all the access to those
properties goes through the proper book-keeping functions. Not only does
this reduce the opportunity for bugs, it makes it far simpler to change
the implementation later if I decide it should be backed by a "proper"
database since everything that directly touches the storage will be
right there in the type definition instead of spread through however
many extensions across however many files.
David, I assume personally you see a benefits of 'private' as it is
currently and don't support extending its scope to "type and subtypes and
extensions in the same module"? My suggestion was to extend it...
Personally I'd like to have a way to say all of this as access scope(in
addition to current public/internal/fileprivate):
1. type only
2. type and subtypes in the same module
3. type and subtypes and extensions in the same module
4. file and subtypes in the same module
5. file and subtypes and extensions in the same module
Probably we could have just (3) without (2), and (5) without (4), need to
discuss if it is important to be able to provide access to subtype but not
for extensions.
So, it seems for me like we need to return 'public' keyword where it was in
Swift2(so to have public/internal/private "file"-based scope), and
introduce well-designed scope access levels with own keywords.
For example, if we really need just (3) and just (5) (without 2 and 4):
typeprivate - type only
typeprotected - type and subtypes and extensions in the same module
typeinternal - file and subtypes and extensions in the same module
Opinions?
- Dave Sweeris _______________________________________________
swift-evolution mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
