> On Dec 23, 2015, at 12:26 PM, Michel Fortin <michel.for...@michelf.ca> wrote:
>
> Le 23 déc. 2015 à 10:07, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>
>> 3) Annoyance. Some consider it to be annoying to have to annotate a class
>> declaration in order to inherit from it. People stating this argument
>> either are either writing a lot of superclasses or are so bothered by the
>> need to annotate their type declarations that they avoid `final` and its
>> related benefits when that is really the right thing for their class. For
>> me personally, `final` is the right thing for most classes I write. I also
>> think adding a `final` annotation is the right thing to do if you’re not
>> sure whether it will be a superclass or not. The need to modify the
>> annotation will remind you that you haven’t fully considered inheritance in
>> your design yet.
>>
>> ...
>>
>> 5) Prototyping. This should also not influence the decision about what the
>> default is for production code. I would not have a problem with a
>> prototyping environment allowing `inheritable` by default (maybe a
>> Playground mode?). There could even be a tool that migrates the prototype
>> to a real project and adds the `inheritable` annotation where necessary.
>> Regardless of what happens here, the prototyping problem can and should be
>> solved independently of the production language and should not influence the
>> default is used in and impacts production code.
>>
>> 6) Education. There may be some value in allowing inheritance by default in
>> education settings, especially early on. I view this as being quite similar
>> to the prototyping case and again should not have an influence on the
>> default that professionals use in production code.
>
> I think these three concerns would be addressed in good part by having sealed
> by default instead of `final`.
>
> I'm not sure why you say the last two should be addressed separately from the
> "production" language. Are you proposing Swift should come in multiple
> language variants?
>
Not exactly.
My point is that it is best to design the language to address production
concerns first. If the defaults in that design cause problems for prototyping
and / or education it is possible to offer an environment with a modified
default. I don’t know if that is a good idea or not. I am not a target user
for either of those use cases (personally, I would rather prototype with the
production language). Either way, it is possible, just as it is possible to
have @testable to facilitate unit testing.
I strongly feel that I shouldn’t pay a price in production code in order to
better support those use cases. IMO ‘final’ is the right default for
production code and we pay a price if the default is anything less, including
‘sealed’.
Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
