[swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp]

I will echo what several other people said in the previous discussion: you have to trust your fellow developers. By declaring a class as “partial” you are allowing that class to be extended elsewhere. Typically that would mean in an adjacent file named ClassName.Foo.swift (next to ClassName.swift). It should be highly discouraged to extend the class using partial from anywhere else, and listing tools can enforce that if needed. But at the end of the day if you can’t trust your fellow developers not to do that then you can’t trust them not to add a new name to the ledger either.

And in case someone was wondering why I’m ok with this and not the “classprivate" idea, the key difference here is that this is opt-in. I’m still not ok with a random extension being able to access private fields of any class by default. Partial classes should be an exception for specific use cases, not a default behavior.

> On Nov 2, 2017, at 5:18 AM, Mike Kluev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> to sum up. so far the feedback on this proposal was:
> 
> 1) generally in favour (e.g. to have ability of adding variables and accessing privates at all)
> 
> 2) the name "continuation" is used for something else
> 
> 3) why not to use partials as they are in c#
> 
> 4) having explicit names for continuations is unwanted because naming is hard
> 
> 5) the ledger list is unnecessary as anyone on the same module will be able to change it anyway - false feel of protection.
> 
> here are my thoughts on it.
> 
> 1) "generally in favour (e.g. to have ability of adding variables and accessing privates at all)"
> -- great! thank you.
> 
> 2) "the name "continuation" is used for something else"
> -- thought the same. let it be "part" instead of continuation
> 
> 3) "why not to use partials as they are in c#"
> -- my belief here is that just because i made my type partial (for my own reasons, e.g. as a result of splitting a single-file class into a multi-file) it does not necessarily mean I want other developers of my team (on the same module) to add continuations / parts to my class. in other words, while there are the module boundaries (the building walls) i still want to see some partitions between the rooms of that building to have some privacy.
> 
> 4) "having explicit names for continuations is unwanted because naming is hard"
> -- every time I am adding extension now I want to label it somehow to indicate it's purpose. if that extensions adds a protocol conformance (e.g. "extension ViewController: UITableViewDataSource") the problem is not as critical as the protocol (or the list of protocols) name itself can serve the purpose of such an indication. if there is no such a protocol conformance however i tend to add a "MARK: ThePurpose" or a comment ("extension ViewController /* ThePurpose */) and as the comments are not checked and get out of sync every time i do this i wish there was a a more explicit extension label in the language for this purpose. maybe that's just me.
> 
> 5) "the ledger list is unnecessary as anyone on the same module will be able to change it anyway - false feel of protection."
> -- to this i can give the same response as in (3). here is another example that hopefully will clarify my point: we shall not really say that "private" in swift is useless and "internal" shall be used instead of it just because anyone in the same module can bypass it anyway: go to your class and change the source from "private" to "internal" for their own benefits, so why bother with private / fileprivate to begin with. so is true in regards to the ledger: yes, it is true that anyone on the team working on the same module has a physical ability to go to my class (the class who's sole maintainer and "owner" is myself) and mess around it, changing it's ledger along the way, or making it partial as in (3) or changing it's privates to internal, or adding variables, etc. it's just they shouldn't, at least not talking to me first. they won't be "behaving properly" if they do.
> 
> some additional thoughts. ledger works similar to the c++ class definition itself, which lists all the members of the class, just on a less granular scope: while in C++ you have to go there every time you want to add, say, a private method, with parts you go change the ledger very infrequently, to add a group or functionalities. another tangentially similar feature of C++ is "friends". if you class have, say, 10 different extensions each implementing a certain feature and you converted them to "parts" the ledger list will contain 10 entries naming those features explicitly.
> 
> Mike
> 
> ps. by now i figured that discussing protection levels in swift is akin to having a wonderful morning walk across a mine field
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution