> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
