I like the ledger list idea better than saying “this class is partial” and now
it can be extended anywhere.
Adam said below that, “you have to trust your fellow developers,” but that’s
BS. You can’t merge a PR to master without approval, and some repos you have to
PR from a fork.
It’s easy to have projects where one Swift module is made up of numerous git
repos. You can silo who is allowed to touch your code that way even within
people working on a single module.
Having a class “partial” where anyone in the module can screw around is
dangerous and therefore un-Swifty.
If devs could be trusted then Swift and git would not even exist.
So I feel it has to be the ledger, guys :D Just saying.
J
> On Nov 2, 2017, at 18:37, Adam Kemp via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
