Hi Tony,
> Sorry to be a (hopefully polite) ogre, but from my perspective, your proposal
> does not address nor nullify the issues with access modifier levels in Swift,
> and I don’t think you should be pitching it as a stop-gap. It could make the
> use of extensions consistent with other similar declarations, but ultimately
> the access modifier level issues remain.
Maybe this will be the case forever: Some people seem to have an affection for
such things that goes far beyond my personal requirements, so I have no idea
what someone else might come up with (I've already been joking about
"cryptographic inheritance", which would allow you to override something only
if you know the right transformation for the checksum of your new
implementation ;-).
None the less, the concept is the most versatile I've have seen so far, yet it
is less complex than some alternatives.
Right now, you can have your private properties in type declarations and
extensions protected from all other types and extensions in the same file, and
people say they want to have this option, so SE-0169 would hurt them.
Other people want same-file extensions to share private parts, and, at the same
time, hide them from alien types in the same file (therefor, they don't want to
use fileprivate).
Those two standpoints could coexist in Swift if we added another access
modifier, but even if someone has a better name than
"fileprivateButVisibleToSameTypeExtensionsInThisFile", this wouldn't be that
nice…
Nested extensions, on the other hand, would require no new modifiers (actually,
it would render fileprivate superfluous), and all you would have to do to have
the effect of SE-0169 would be putting your extensions between an existing pair
of curly braces, instead of placing them below that block.
I don't know about your specific issues with access levels, but the ones I have
read about can be solved.
> - Can you clarify for me: does this proposal suggest allowing extensions on
> the enclosing type to be nested within the type declaration, or within other
> extensions on the original type? If so, can you please word that more clearly.
Both: Whatever is possible outside the curly braces should be possible between
them as well (at least I have no spontaneous example for something that should
be forbidden).
> - I would like to see some examples of the proposed syntax included in your
> proposal (perhaps via a link to the markdown source on GitHub?). Best case
> and worst case examples would show what impact it will have on readability
> and file length when someone goes a bit nuts with this feature.
No rules will stop people doing stupid things, but I'd rather give the people a
tool they could use to harm their codebase, instead of bugging all users of
Swift by trying to make it foolproof.
The linked discussion has an example - I'll attach it here as well, because the
HTML has no syntax colouring ;-)
> - Do you know how much work will be required to implement this change at this
> stage? Is it feasible within the bounds of the time remaining before Swift
> 4’s release?
Well, one major positive aspect of the idea is that there is no need to hurry:
I have an impression that we are in danger to make decisions without taking
enough time to think about their consequences, just because a proposal should
be part of the next release.
Nested extensions wouldn't break anything, so we could just leave this topic
alone for now and include it in Swift 5 or 6 — or never, I someone has a better
idea in the meantime.
SE-0169, on the other hand, would be yet another breaking change, and some
people think it would harm Swift 4 and possible all versions to come after...
> Off-topic suggestion: Using the words “Simply” or “just” when describing work
> to be done by others is something that you should avoid (unless you’ve
> already implemented the feature and there’s a PR sitting on GitHub, ready to
> go). Removing those words allows the sentences to communicate the same ideas,
> but they no longer trivialise the size/scope of the work to be done during
> implementation.
Oh yes, especially that last one — I did not find the fitting word yet, but I
have to agree that this part could be interpreted in a way that wasn't intended.
> At this stage, I’m really not sure whether I’d add my support for this
> proposal were it to go to review, but hopefully my comments are useful.
Well, I expected little more than a handful of comments saying "I like X
better" and general disregard, so "I might support it" is already quite
positive ;-)
- Tino
class MyVC: UIViewController {
private let numberOfSections = 0
extension: UITableViewDataSource {
// Skipping the class and assume we want to extend the surrounding type
func numberOfSections(in tableView: UITableView) -> Int {
return numberOfSections
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section:
Int) -> Int {
return 0
}
}
private extension {
// this would contain everything that shoudn't be visible for other
extensios
var secret: Int = 0
public extension MyFriendClass {
// oh, well, I make an exception here for a trustworthy type
func checkSecret(of controller: MyVC) -> Bool {
return controller.secret > 0
}
}
private extension {
// this is so secret, I'm not even allowed to copy it
}
}
public func myMethod() {
print("This is just a boring method")
}
}
It has the downside of shifting code to the right (you could as well leave
those extension-blocks unindented), but lots of advantages:
- No change for private needed
- It can be nested as much as you like to satisfy even the most absurd desires
of encapsulation
- It reminds me on operator definitions inside type declarations
- No change for fileprivate needed (but actually, I think there is very little
need to keep fileprivate)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
