> On 6 Jul 2016, at 00:11, Chris Lattner via swift-evolution > <[email protected]> wrote: > > Hello Swift community, > > > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the proposal?
-1 In general terms, the philosophy “you are not allowed to do stuff with my classes unless I say so” is repugnant to me. Also, the breakages in existing code would be more serious than usual. The specifics: Firstly, making a class public does not provide “two different” capabilities, it provides one: the class is now accessible outside the module. Using a class includes instantiating it, calling functions, accessing properties and also subclassing non final classes and methods. If you choose to make a method or class public you are already having to carefully consider its design perhaps adding guards for parameters validationetc. In this context, adding final is not really onerous. Secondly, if you don’t want to go to the trouble of making your class work properly, you already have the option of making it final. Thirdly, this is a huge breaking change. Not only is it a breaking change, but for a lot of people, the breakages will be outside of their control. Consider if I publish a module with a class with public methods and you subclass it in your code. Once this change is implemented, my code will still compile and pass its unit tests but your code is now broken and you are dependent on me changing my code to fix your code. Fourthly, the optimisation point is a red herring. Premature optimisation is the root of all evil, they say. This is premature optimisation. In any program, the number of methods where eliminating dynamic dispatch would provide a visible benefit is tiny. In those cases, you can add the word final to the declaration (after proper performance testing). > * Is the problem being addressed significant enough to warrant a change > to Swift? The functionality to stop people subclassing and overriding where it would be dangerous to do so already exists and this coupled with the serious problem of breaking code where the fix is outside the developer’s control makes it a very bad change indeed. > * Does this proposal fit well with the feel and direction of Swift? No. Swift feels to me like a really nice powerful language that is easy to program in. Hopefully the direction of Swift is more of the same. This change is going the other way. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I have used many languages with classes with inheritance: Java, C++, Python, Objective-C, C#, Smalltalk. They all more or less follow the current Swift convention (in C++ you had to explicitly say if a method was virtual and that could be quite confusing). > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? I read the proposal and some of the other responses. > > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris Lattner > Review Manager > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
