2016/07/15 16:37、Riley Testut via swift-evolution <[email protected]>
のメッセージ:
> FWIW, I'm still against this proposal, but since it will be accepted
> regardless, here are my thoughts:
>
> • Open keyword is significantly better.
> • Members should be *open* by default, and final should be opt-in. If you're
> opening up a class for subclassing, my gut says you should allow the client
> to do as they wish.
If you have a class that was not open yet, just making it open wouldn't expose
any members: it would then just be subclassable.
If the act of making the class open doesn't implicitly make overriding
possible, well all you can do then is add methods, and that can be done with
extensions anyways, so it's not as useful and makes the public open class {}
pattern just by itself not so useful imho... 😬
Also, the keyword 'open' itself may imply 'hey I'm open, please do what you
want with my public members', whereas 'subclassable' is more specific in
intention... (but that's just me, so n=1 and all that)
TLDR; +1 to the above: simpler is better and defaulting to overridable for
public members on an open class is simpler... invariants can be protected by
the 'final' keyword.
If we were to default to non-overridable, a more consistent 'open' on the
method is preferred over overridable for me... open class, open method... much
better imho...
> If only one or two methods should be overridable, I think delegation (via
> protocols) is a much better solution.
Delegation and protocols all the way!
> • I feel like final and open are now *almost* on the same axis, but not
> quite; open controls subclassability outside module, but final controls it
> for both. Why not use access control modifiers, such as:
>
> - public(open)
> - internal(open) (default)
> - fileprivate(open)
> - private(open) = final
>
> Then, we could remove the "final" keyword from the language completely, and
> use access control as normal. I feel like this unifies everything much better
> (private(open) does seem a little weird though).
I think it does feel a little weird, and maybe makes things more complicated...
for example, private(open) by itself doesn't tell me at a glance what consumers
of the framework will see... maybe this because of the 'open' being there... it
feels like just plain 'private' is better... then I can reason, 'oh this is
only a private class, I'm the author so I can do what I want here' or 'oh, this
ones public but not open'... maybe I'm wrong though.... 🙃
Thanks,
Andre
> On Jul 15, 2016, at 1:27 AM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
>>> On Jul 14, 2016, at 2:39 PM, Chris Lattner <[email protected]> wrote:
>>>
>>> asks the community for an in-depth discussion of the secondary points of
>>> the proposal: does it make sense to require every member to be marked as
>>> “overridable” in order to be overridden by an open subclass outside of the
>>> current module?
>>
>> To be clear: You want this discussion to happen in the next review thread,
>> rather than in this thread?
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> 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
