[swift-evolution] [Review] SE-0117: Default classes tobenon-subclassable publicly

[Leonardo Pessoa]

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

-----Original Message-----
From: "Tino Heth" <2th at gmx.de>
Sent: ‎10/‎07/‎2016 05:47 PM
To: "Leonardo Pessoa" <me at lmpessoa.com>
Cc: "swift-evolution" <swift-evolution at swift.org>; "Jean-Daniel Dupas" <mailing at xenonium.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160710/adbb50f0/attachment.html>