On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:
Hi, -evolution. I’ve said this before, but *I think this new proposal is a
terrible idea*. It privileges types in a way that is damaging to the language.
[There isn't really anything new in my discussion below; everyone on-thread
is smart enough to have brought up these points already. But I wanted to go
on record about it, at least.]
Thank you for sharing your opinion regarding this subject.
Do I understand correctly, that *you* propose to just revert access levels
and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private' and
rename 'fileprivate'->'private')
Or do you support to leave current 'scoped-private' under another name?
Vladimir.
The claimed problem with the current version of 'private' (let's call it
"scoped-private") is that it encourages developers to make monolithic type
declarations instead of using extensions. With the proposed new
interpretation (let's call it "extension-file-private"), there's a similar
problem: developers are encouraged to put everything in the original type
even when it may be more appropriate to
1. Extend another type (e.g. converting initializers)
2. Use a helper type (a nested type always inherits the generic parameters
of its enclosing type)
3. Break a single protocol or class out into a hierarchy (subtyping should
be used /sparingly/ but not /never)/
Of course, one can always add an extension to access the
extension-file-private members from outside the type, but that just
underscores how little expressive power this level would actually have.
These are cases where 'fileprivate' is the /correct/ tool for the job.
I liked the original three levels of access (not a surprise to anyone,
since I was a primary designer), and one reason for that is that the access
levels are /completely indepedent/ of the declarations you're writing. You
can organize your code in whatever way makes the most sense, and the access
levels will then help you enforce that organization. I do think SE-0025
should not have been accepted, that it does not add enough benefit given
the increase to complexity, but even scoped-private can be used as an
organizational feature that prevents you from making mistakes, and it still
offers a simple answer to where a declaration can be used.
The proposed extension-file-private exposes a declaration to an arbitrary
subset of the file it's in, because being within an extension of a type or
not is arbitrary with regards to code organization. Extensions /are/ used
organizationally, but there's now no way to distinguish whether the private
members of /this/ extension are related to the private members
of /that/ extension, or whether they were supposed to be independent.
Everyone is acting like "fileprivate" is a problem. While we may not like
the name, /it's still the right tool for the job./ What else do you have in
the file that you're trying to protect?
Let's not add a mishmash of a feature just because it's "practical" for
some uses.
Thanks for hearing me out,
Jordan
P.S. I have a /lot/ to say on the idea of "submodules", and the dozen
different things people want from them. I'll try to write that up later, so
that people can refer to it if/when we ever get around to discussing such
features. But it's not relevant right now.
_______________________________________________
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
