Should I assume then you want so much this proposal to be dropped you didn't even mind to look for the example so you wouldn't have to admit this proposal is needed? Fine, here is the whole of that example.
I'm currently working on an app which will have object representations of Files and Folders (both come from a common class called Entry). You as a developer for this system will be entitled to extend from File and Entry freely but you can only work with Folders and its subclasses (specialised folders) but to this system it is important you don't subclass any type of folder. Without this proposal I would have to create workarounds to prevent you from doing that while still allowing me to subclass while playing a lot of finals everywhere. And so far I would have to allow you to subclass Folder itself (at least) but you would complain (and possibly file a bug report to me) because it would not be working properly because your classes would not benefit from the workaround. In this case, if I could subclass internally but prevent you from doing it, you could complain I'm not allowing you to do whatever you want but you wouldn't complain my code doesn't work properly (it does, you just won't know it). There may be several more examples but this is one I'm facing right now, so I can assure you it is a true example. IMO libraries are to be written with intention in mind and I don't think it is right to use a library written to compose a PDF file to send an email (even if you're sending the PDF file attached, the right way to do it is by composition not subclassing). Additionally, someone mentioned and I went in to check about a recommendation for Java to intentionally document and enable classes to be subclasses explicitly otherwise forbid it at all and that recommendation seems to come from Oracle itself. I believe Oracle would do it to Java if it had great interest in it without consulting anyone's opinion. About the addition to the proposal to enable force unsealing, I'm completely opposed as it is just like not having any of this protection at all (why putting a lock on the door to your house if the key is under the mat?) Swift doesn't have to follow on the footsteps of any language but what is best for the intention the language was created for. If sealed by default goes in that direction, then we should have it not looking back. The same goes if we decide this is not taking the language in its intended direction. If I'm not wrong at least one member of the core team already mentioned in this thread this is completely aligned with the intention of the language, so I think we should give it a go and stop trying to have/keep control of everything we touch. L -----Original Message----- From: "Tino Heth via swift-evolution" <swift-evolution@swift.org> Sent: 10/07/2016 01:55 PM To: "swift-evolution" <swift-evolution@swift.org> Cc: "Jean-Daniel Dupas" <mail...@xenonium.com> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something. I got a single reply — which did not contain an example, but just the claim that there is one… Imho that alone should be enough to cancel the whole thing, because even if there are cases which cannot be repelled with the simple advice "just don't subclass", this would only be a basis to start talking about the actual pros and cons. So for me, the promised benefits are less likely than the existence of Bigfoot: I guess there are at least several hundred people who swore they have seen him, and there are even some blurry photos ;-) Of course, it is impossible to come up with an unquestionable argument for the change — and it's also impossible to prove the opposite, because the whole debate makes as much sense as arguing wether raisins are tasteful or terrible; it's nothing but personal preference, and the only thing we can hope for is that the bias of those who will decide this proposal isn't at odds with the needs of the majority. If we can agree that it is not about facts, but about opinion, there are still fundamental arguments against SE-0117: Those who have issues with subclassing can just resign from it (as users of a library), and they can annotate their classes to dictate their usage (as an author) — but if you think subclassing is still a good tool, you can't do anything with a sealed class. Additionally, please note that those who ask for stricter rules and more regulation have many reasons to be happy with the status quo: You can subclass neither structs nor enums, and by default, you can't inherit from a framework-class as well, because it is internal — and yet they yell for more. Swift claims to be opinionated, not to aim for compromise — but if plain old OO isn't compatible with the ideals of the language, it would be more honest to just completely remove inheritance instead of slowly crippling it's possibilities. - Tino _______________________________________________ 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
