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" <[email protected]>
Sent: 10/07/2016 05:47 PM
To: "Leonardo Pessoa" <[email protected]>
Cc: "swift-evolution" <[email protected]>; "Jean-Daniel Dupas"
<[email protected]>
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
