Interesting example but it only explain that a sealed keyword is needed (which I agree), and not why sealed should be the default (which I disagree).
> Le 10 juil. 2016 à 21:18, Leonardo Pessoa <[email protected]> a écrit : > > 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 > From: Tino Heth via swift-evolution <mailto:[email protected]> > Sent: 10/07/2016 01:55 PM > To: swift-evolution <mailto:[email protected]> > Cc: Jean-Daniel Dupas <mailto:[email protected]> > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
