On 7/6/2016 1:52 AM, Chris Lattner wrote: >> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution >> <[email protected]> wrote: >> >> * What is your evaluation of the proposal? >> >> -1 as is. I do not want to be constrained by authors of libraries or >> frameworks into interacting with a system in only the ways they forsee. >> By making the default be non-subclassable, if a designer does not put >> thought into all the ways a class can be used then I as a consumer of >> the library am penalized. > Out of curiosity, what is your feeling about “internal” as the default level > of access control? It seems that following your concern to its logical > conclusion would lead to a design where all members of a public class would > be forced to be public. After all, the author of a library or framework may > not forsee the need to interact with a member that they did not explicitly > mark public. > > -Chris
I can appreciate this argument, but I would hope that my viewpoint is a bit more nuanced than that :). To turn the tables a bit, one could argue that, taken to the proposal's logical conclusion, writable properties should not be publicly writable for safety's sake. Instead, they should be required to be explicitly marked as publicly settable if needed as it should be up to the author of that type to carefully consider how safe it is for others to mutate the state of their types. Yet today both sides of a property are given the same access level unless one explicitly restricts the visibility of it's setter. The current behavior (of properties specifically, and the access control feature as a whole) achieves a balance of convenience, power, and safety that I am happy with. The proposed change however sacrifices too much convenience for a greater sense of safety and control by default. It's not possible to accidentally override a method like it is in java or objective-c, so the proposal won't help people who might accidentally override something. If a developer tries to override a method or class they probably have a specific reason in mind for doing so, and taking away the options that this ability presents, by nature of it being the default behavior, doesn't sit well with me as it has the potential to take away a good tool from my toolbox. I agree that API authors should have the power to restrict this dimension of a type's usage, but I feel that it should be a conscious choice to do so. - Kevin _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
