+1 except for the choice of names if I understand it correctly, but I want to
make sure I understand it correctly.
The scenario I want to to make sure I understand is what happens for a
class-cluster type pattern like the following:
// Module A:
public class PublicBaseClass {
func someMethod() { /* placeholder here */ }
}
private class PrivateSubclass : PublicBaseClass {
override func someMethod() { /* new logic here */ }
}
…I think this would make `PublicBaseClass` effectively “final” (e.g.
non-subclassable) from outside of Module A, but `PrivateSubclass` (and similar
constructs, etc.) would still be allowed and work as one would expect?
If so, that’s what I’d want semantically, so +1 on that for the semantics.
*But*, that behavior means that it is *very* confusing to be using
`subclassable` and `overridable` for what they mean in this protocol.
I usually stay out of bike shedding but these attributes are really poorly
named IMHO; I’d *highly recommend* something like either the ugly-but-explicit
`externally_subclassable` / `externally_overrideable` or something else
entirely (like maybe `open`?) that avoids the confusion.
Apologies if this has already come up or is based upon a misunderstanding of
the proposal.
> On Jul 5, 2016, at 6:11 PM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> Hello Swift community,
>
> The review of "SE-0117: Default classes to be non-subclassable publicly"
> begins now and runs through July 11. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift. When
> writing your review, here are some questions you might want to answer in your
> review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> _______________________________________________
> 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
