> This is bad faith. The original discussion contains many real life example.
"bad faith"? Really? If we have the same interpretation of this phrase in our
dictionaries, it's only fitting here as attribute for the sentence following it.
I took a position that is extremely easy to attack, yet the only counter
argument is the claim that there are many real life examples (instead of citing
a single one). That's just "alternative facts", and it tells a lot about the
actual power of the arguments that are used to justify forbidding subclassing.
Afaik, there hasn't been a single real life example by those who fought for
"final by default", and it took quite a long time until someone from core came
up with a scenario which illustrated a disadvantage of non-final classes in a
lib — but that example had bad (worse) consequences in a final-by-default setup
as well, so it wasn't convincing for me.
First step in discussion should be agreeing on facts, and in this discussion,
imho the most important fact is that this actually isn't about facts at all,
but rather about opinion and personal preferences:
When someone suggests to rename the keyword "func" to "fn" or "function", it is
ridiculous to argue that either choice is better, and the same is true for this
topic (it just has bigger consequences).
When you actually read the original discussion, I expect you will find more
false claims and questionable tactics from both parties than valuable examples,
and this drags down the quality of the debate.
> You just don’t want to admit open is useful for many library writers.
Of course open is extremely useful for library writers — especially for those
who write libraries that are intended to be actually used…
Did anyone question that? (I guess the title of the thread can be a little bit
irritating, but afaics, it is only the keyword that should be removed, not the
feature itself).
As I told the author of this draft, I can only tell its opposers as well:
Just relax and admit that you are not fighting for the better choice, but only
for the one you like better.
(btw, that is the case for a lot of decisions:
Typed throws aren't better than untyped ones, zero-based arrays aren't better
than 1-based arrays, functional programming isn't better than POP or OO,
composition isn't better than inheritance, structs aren't better than classes…
the strongest statement you can make for some of those alternatives is that
they perform better in specific situations)
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution