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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution