IMHO SE-0117 is one of the worst Swift 3 proposals that have ever been proposed. It has the potential to make the language much worse. I haven't seen any problems at all that are caused by people trying to subclass classes that they shouldn't, so I'm wondering where this fear of bad subclass behavior comes from. And for the performance argument: there is no performance benefit of this proposal. I cannot prove this of course, but you'll remember my words in a year or so, when this proposal has been adopted and we can measure the alleged benefits of it. I can already see how this "feature" will be rolled back for Swift 4 ;)
I'm not against change in general. I think going from Swift 1 to Swift 2 was a big improvement. Swift 2 to Swift 3 is overall okay, but it gets worse by introducing things like NoReturn/Never or sealed subclasses. -Michael > Am 11.07.2016 um 00:53 schrieb Leonardo Pessoa via swift-evolution > <swift-evolution@swift.org>: > > Yes, app. Apps can be extended through plugins and you cannot write a plugin > to an app without a library that exposes what you can do. That alone can > expand my simple sample into a variety of examples: plugins. > > For the many types of folders I cannot enter details of my app now but check > macOS' folders: aside the basics you have smart folders, disks, remote > folders and so forth. They follow the same basics but some specificities will > vary. You can create as many different files you want but can you create a > new type of folder there? Same here. > > Too bad my example did not convince you but subclassing to fix bugs also > don't convince me. I really believed this is the behaviour that leads bugs in > a library not to be fixed: because instead of helping improving the library > for everyone you fix it for yourself and let it go. The developer of the > library doesn't even care to fix the bug since everyone uses your subclass > fix or he finds out purple doing this, fixes the bug and puts a final there > breaking everyone's app. > > L > From: Tino Heth > Sent: 10/07/2016 05:47 PM > To: Leonardo Pessoa > Cc: swift-evolution; Jean-Daniel Dupas > Subject: Re: [swift-evolution] [Review] SE-0117: Default classes > tobenon-subclassable publicly > > >> 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. > This list has thousands of messages, this topic alone is split into at least > six threads… I tried, but how much time should I spend searching without any > helpful hint? > But let's see what we got now... > >> I'm currently working on an app > wait a minute: An app, not a library? What difference will sealed make here > at all? > >> 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). > So, how many types of directories may exist that you would have to mark as > final? (serious question — please don't ignore it) > I don't know about you specific model, but for me, invisible directories and > bundles would be all I'd be worried about — and those are basically all > normal folders as well… > So, do those subclasses each have special properties? There is only a limited > set of metadata a directory can have, so I expect there is no need for > subclassing at all: Is there a special reason why it can't be a single class, > or an enum? > This may all be useless advice that doesn't work for your case — but if I > stick with the Sasquatch-metapher, this is a very blurred picture... > >> 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). > How is this statement connected to the proposal? > The only way to prevent misuse of software is not to write it; and what harm > is done to you as the author of a PDF-lib (btw: been there, done that — nasty > format ;-) if some stupid user turns your composer into Emacs? > >> 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. > good point… Oracle is widely known for its instinctive knowledge about the > needs and problems of their customers — which they than tend to ignore and do > something different ;-) > >> 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?) > As long as we don't speak about commercial libraries, which are a curiosity > in the Swift-cosmos: > There is no lock, there is not even a door — there is only a tiny sign that > says "please don't enter", and the worst thing that could happen if you > ignore it is that the original owner stops doing the housework. > >> 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. > Isn't this exactly what this proposal is about? Replacing freedom with > control? Stop trying to keep control of everything is actually a good idea in > the light of this proposal. > > I appreciate that you described your case, but it didn't do anything to > convince me. > > 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