I like the point someone made about unit testing. If subclassing was disabled then I think there should then be some way of mocking built into the testing frameworks of swift (Think RSpec but for switt)
On Tue, Dec 22, 2015 at 12:51 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Dec 22, 2015, at 3:43 AM, Tino Heth <2...@gmx.de> wrote: > > > I can see why you view it this way, but access control and inheritability > are orthogonal. > > as I understand orthogonal (mathematical background), it is definitely not > the case: > I can't inherit what I cannot access, so there is one impossible > combination of the two attributes. > > > Ok, you got me there. Orthogonal was not the best choice of words. > Nevertheless, they are independent concerns that happen to interact in this > one case. > > > The argumentation that "users of your framework could cause trouble (what > they will do anyways ;-) with overriding" looses traction when you have to > add "of cause that only applies to classes you made explicitly accessible > to them". > > Final is right in theory, but in real software, classes are rarely > designed for inheritance — it just happens (and I'm quite sure most real > software is build by people who would shrug of such discussions as academic > nonsense ;-). > > > If the time comes it is certainly a good thing if the language can remind > you of the fact that you didn't consider it in the initial implementation > by requiring you to mark the superclass inheritable. > > > Btw: I wouldn't oppose a proposal to allow changing conventions like this > (there are at least two other discussions about the best default) on a per > module/file basis — as long as the "local" effect of the setting isn't > vital, there shouldn't be a problem with customizing. > > > I would really be opposed to this. It would not be clear when reading > code what it actually means. Copy and paste would also be problematic for > similar reasons. Flags should not change the semantics of a piece of code. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Wizard ja...@supmenow.com +44 7523 279 698
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution