Sent from my iPad
> On Dec 22, 2015, at 3:43 AM, Tino Heth <2...@gmx.de> wrote:
>
>
>> I can see why you view it this way, but access control and inheritability
>> are orthogonal.
> as I understand orthogonal (mathematical background), it is definitely not
> the case:
> I can't inherit what I cannot access, so there is one impossible combination
> of the two attributes.
Ok, you got me there. Orthogonal was not the best choice of words.
Nevertheless, they are independent concerns that happen to interact in this one
case.
>
> The argumentation that "users of your framework could cause trouble (what
> they will do anyways ;-) with overriding" looses traction when you have to
> add "of cause that only applies to classes you made explicitly accessible to
> them".
>
> Final is right in theory, but in real software, classes are rarely designed
> for inheritance — it just happens (and I'm quite sure most real software is
> build by people who would shrug of such discussions as academic nonsense ;-).
If the time comes it is certainly a good thing if the language can remind you
of the fact that you didn't consider it in the initial implementation by
requiring you to mark the superclass inheritable.
>
> Btw: I wouldn't oppose a proposal to allow changing conventions like this
> (there are at least two other discussions about the best default) on a per
> module/file basis — as long as the "local" effect of the setting isn't vital,
> there shouldn't be a problem with customizing.
I would really be opposed to this. It would not be clear when reading code
what it actually means. Copy and paste would also be problematic for similar
reasons. Flags should not change the semantics of a piece of code.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
