On 22.02.2017 11:26, Jonathan Hull via swift-evolution wrote:
On Feb 21, 2017, at 11:47 PM, David Hart <[email protected]> wrote:
On 22 Feb 2017, at 08:37, Jonathan Hull <[email protected]> wrote:
I fully agree. I actually think that applies to both solutions
though. As much as I would like to see the mess around private
fixed, I think it needs to be as part of a well considered redesign
of the access system that adds enough functionality to stop this
cycle. We can’t just rename things or flip back and forth between
options every 6 months.
As an example of what I think *is* an appropriate change is Nevin’s
suggestion on another thread to add a single level of submodules
(which group files). As part of this change, ‘private’ would mean
private to the submodule (or file if the file is not part of a
submodule). Internal/Public/Open would remain unchanged. Thus you
have only private, internal, and public/open… but the fix came as
part of unifying with other improvements (and is not just returning
to pre-0025).
I saw this but it looks very confusing for me: private would mean
different things in different contexts and I would have no way to make
things private to a file in a submodule.
Nor would you have a way to make things private to a particular scope.
Private would always mean private to the submodule (and files without an
explicit submodule would be an implicit anonymous submodule). I like the
simplicity. You can basically think of it as Swift 2 private, but with
the allowance to split things up into multiple files.
Anyway, my main point (regardless of what people think of that
particular proposal) is that we need to fix the underlying issues with
access (not just rehash 0025).
Yes, I believe we all(most of us) agree "we need to fix", but in different
ways.
And while one thinks of 'simplicity' as more easy way to *write* the
code(don't need to think about access levels), other thinks as more easy
way to *use* and *support* code(own or other's), when you can attentively
configure access levels and get help from compiler in case one (even by
mistake) is touching what was *not designed* to be touched.
From my point of view the "underlying issues with access" is that we have
no well-designed scoped access modifiers in addition to module/file access
levels. I do think they are two axis of the access control/documentation,
and should work together to aim the better code quality and 'simplicity' in
all meanings.
The one way I can think of scoped access modifiers is that they should have
explicit and clear naming, even if this will lead to more massive syntax
(like Matthew Johnson suggested scoped(scopeName)). While keep
public/internal/private(as was in Swift2) names simple and easy to use.
for example,
// File.swift
class C {
scoped(type) var veryPrivateProp1 = 1
public scoped(type:set) var veryPrivateProp2 = 2
scoped(subtype) var akaProtectedProp3 = 3
scoped(extension) var accessFromSubtypeAndExtension = 4
// as it is common to give access to internals inside the same
// file, IMO we need also this:
scoped(file,subtype) var insideThisFileAndSubtypes = 5
scoped(file,extension) var insideThisFileAndSubtypeAndExtension = 6
// as a variant, currently "friend" means any code inside the file:
//scoped(friend,subtype) ...
//scoped(friend,extension) ...
// ex: property, that can be changed only inside this type or
// subtype, but can be accessed from extensions and inside this
// file
scoped(file,extensions) scoped(type,subtype:set) var myProp = 7
}
Just as the "food for thoughts"..
Thanks, Jon
Thanks, Jon
On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution
<[email protected]> wrote:
Well-written as-is.
Overall, my feedback is that solution 2 should not be on the table
(though there are people who clamor for it), and not because I
don't agree with it. However, simply as a matter of following an
appropriate process, solution 2 was originally proposed in
SE-0025, fully considered, and modified by the core team to the
current design. One can disagree whether `scoped` is more
appropriate than `private` as a name for that access modifier, and
one is likely to say that `private` looks nicer than
`fileprivate`, but that's neither here nor there. The
appropriateness or niceness of these terms is unchanged from last
year. Re-submitting SE-0025 cannot be the solution for fixing
SE-0025.
_______________________________________________ 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
