On 29.06.2016 22:05, Michael Peternell wrote:
I'm still unhappy about this "sealed by default" proposal. That really
looks like premature optimization to me. Instead there should be some
`sealed` keyword. Maybe it should be called `applepublic` :-p Everyone
will understand!
I understand your point of view. But I also think about the proposal as
forcing the developer of public(! i.e. usually which exported from some
framework) to carefully think if he/she really wants to allow exported
types will be extensible. Not just about performance.
And as was mentioned, 'sealed' is not 'final' : you can extend the sealed
type in internal scope, but it will be final for public scope. (If I don't
miss something)
But, yes, I'm also not sure if we should seal by default and not introduce
`public(final)` or `public(sealed)` access modifier for those who
explicitly don't want to allow extension of exported class.
`sealed` classes should be a special optimization used by optimizing
developers who ask for it. Don't make it an unwanted and un-asked-for
default optimization. The people who care for optimization much will
learn about `sealed` and be able to apply the concept in both cases. The
people who don't care about performance will just be disappointed by the
"implicitly sealed" behavior. And with this proposal, when I read
`unsealed` I can never know: "did this developer intend me to be able to
subclass this class? or did he just not want to restrict me
unnecessarily?" The documenting aspect of `unsealed` is so small.
And `sealed` is just an optimization; IMHO the magic of static dispatch
lies in final classes or final methods. Sealing everything by default
just marks many classes and methods as implicitly final (because it can
be proven that they are not subclassed). I just don't think that all
these theoretical performance improvements are really worth the trouble
in practice.
-Michael
Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution
<[email protected]>:
How about `public(extensible)` ?
On 29.06.2016 21:32, John McCall via swift-evolution wrote:
On Jun 29, 2016, at 11:16 AM, Michael Peternell via
swift-evolution <[email protected]> wrote: Do you mean
`public(unsealed)`? Because `internal(unsealed)` doesn't really
make sense. `internal` declarations are always sealed.
Right.
If "sealed" is the default behavior for public classes and methods —
and I don't think the modifier is worth adding unless it's the
default — then we need a way of "unsealing" classes and methods
that's fairly pithy. I don't think a parenthesized spelling is good
enough for that. And we should try to make the positive form ("can
be overridden") shorter than the negative ("cannot be overridden"),
because the latter will not usually be written.
To me, the ideal spelling would be usable in place of "public". If
it does have to be stacked with "public", then I think it ought to
be pretty short.
"communal"? :)
"open" doesn't carry quite the right meaning, and it would need to
be paired with "public", I think.
John.
-Michael
Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution
<[email protected]>:
Do we really need a new keyword? Since we already have syntax
like `internal(set)` couldn't we do `internal(unsealed)`, etc.
On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via
swift-evolution <[email protected]> wrote:
On Jun 29, 2016, at 12:15 PM, Michael Peternell
<[email protected]> wrote:
Am 29.06.2016 um 15:54 schrieb David Sweeris via
swift-evolution <[email protected]>:
+1 for the concept of a "sealed” class. -1 for making it
default.
Aren't sealed classes already implemented? I think the keyword
is `final`.. So there is nothing left to do :)
No, `final` doesn’t allow for any subclassing, but `sealed`
allows for subclassing within your module (where you can
presumably write more efficient code based on knowledge of each
subclass).
- Dave Sweeris _______________________________________________
swift-evolution mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
