[Review] SE-0117: Default classes to be non-subclassable publicly


(Jon Hull) #1

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which something will need to be extended. You think you know, but are then surprised by creative uses. My favorite features of Swift/Cocoa involve retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of forcing people to think about subclassing more. It will just add confusing boilerplate.

Things like Swift optionals work well because they make the (often forgotten) choices explicit in the context that they are used. In the world of Human Factors, we call it a forcing function. This proposal has the inverse structure, and will be ineffective, because the “forcing” part of it shows up in a different context (i.e. trying to use a framework) than the decision is being made in (writing the framework). This type of thinking leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I predict this proposal would not only fail in increasing framework quality, but also will make it much harder for users of those frameworks to work around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about their design would have been anyway. Those who are not thoughtful about their design will just leave these annotations off… leaving us with no recourse to extend/modify classes. When people complain, they will add the annotations without actually thinking about the meaning (i.e. stack overflow / the fixit tells me I need to add this word to make the compiler happy). All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space. If we truly want to solve the issue of subclassing, we need to consider all of the common issues which arise. Looking at the cocoa documentation you will see several types of annotations:
  1) This method MUST be overridden
  2) This method should NOT be overridden
  3) This method MUST be called
  3) This method should NOT be called except by subclasses
  4) This method should NOT be called except by a method override calling super
  5) This method MUST call super
  6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I would like to see things be extendable by default, but with annotations that thoughtful framework designers can use to designate how a particular method should be used. In most cases, it should not explicitly forbid the end user from subclassing, but require them to acknowledge that what they are doing is not intended by the framework. (e.g. "unsafe override func"…). That would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate while failing to achieve its objective. It goes against the retroactive modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other languages that lock things down, there is a need to unlock things soon after (e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking for the ability to patch/override in cases where the framework designer was wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access control that touched on this subject as well. I have been designing frameworks for years.

Thanks,
Jon

···

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


(Tino) #2

totally agree:
I'm not sure what 3) should mean, but imho several points on this list are much more useful than the ability to seal a class.
Imho it is not necessary to forbid overloading at all, it's better to make sure everyone trying to do so is aware of the dangers (imho exclamation marks would be a "swifty" choice: "override! func(…)).

···

Am 07.07.2016 um 02:27 schrieb Jonathan Hull via swift-evolution <swift-evolution@swift.org>:

  1) This method MUST be overridden
  2) This method should NOT be overridden
  3) This method MUST be called
  3) This method should NOT be called except by subclasses
  4) This method should NOT be called except by a method override calling super
  5) This method MUST call super
  6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I would like to see things be extendable by default, but with annotations that thoughtful framework designers can use to designate how a particular method should be used. In most cases, it should not explicitly forbid the end user from subclassing, but require them to acknowledge that what they are doing is not intended by the framework. (e.g. "unsafe override func"…). That would feel 1000x more swifty to me. Opt-out safety.


(Jean-Daniel) #3

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other times to workaround bugs in the library. Or even to extends the library in a way that the author did not intent in the first place, but that was perfectly supported anyway.

I already see how libraries author will react to that new default. They will either don’t care and mark all classes as subclassable, or find to burdensome to get subclassability right and prohibit subclassing all classes.

···

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which something will need to be extended. You think you know, but are then surprised by creative uses. My favorite features of Swift/Cocoa involve retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of forcing people to think about subclassing more. It will just add confusing boilerplate.

Things like Swift optionals work well because they make the (often forgotten) choices explicit in the context that they are used. In the world of Human Factors, we call it a forcing function. This proposal has the inverse structure, and will be ineffective, because the “forcing” part of it shows up in a different context (i.e. trying to use a framework) than the decision is being made in (writing the framework). This type of thinking leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I predict this proposal would not only fail in increasing framework quality, but also will make it much harder for users of those frameworks to work around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about their design would have been anyway. Those who are not thoughtful about their design will just leave these annotations off… leaving us with no recourse to extend/modify classes. When people complain, they will add the annotations without actually thinking about the meaning (i.e. stack overflow / the fixit tells me I need to add this word to make the compiler happy). All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space. If we truly want to solve the issue of subclassing, we need to consider all of the common issues which arise. Looking at the cocoa documentation you will see several types of annotations:
  1) This method MUST be overridden
  2) This method should NOT be overridden
  3) This method MUST be called
  3) This method should NOT be called except by subclasses
  4) This method should NOT be called except by a method override calling super
  5) This method MUST call super
  6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I would like to see things be extendable by default, but with annotations that thoughtful framework designers can use to designate how a particular method should be used. In most cases, it should not explicitly forbid the end user from subclassing, but require them to acknowledge that what they are doing is not intended by the framework. (e.g. "unsafe override func"…). That would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate while failing to achieve its objective. It goes against the retroactive modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other languages that lock things down, there is a need to unlock things soon after (e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking for the ability to patch/override in cases where the framework designer was wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access control that touched on this subject as well. I have been designing frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #4

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

···

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override
arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other
times to workaround bugs in the library. Or even to extends the library in a
way that the author did not intent in the first place, but that was
perfectly supported anyway.

I already see how libraries author will react to that new default. They will
either don’t care and mark all classes as subclassable, or find to
burdensome to get subclassability right and prohibit subclassing all
classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which
something will need to be extended. You think you know, but are then
surprised by creative uses. My favorite features of Swift/Cocoa involve
retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of
forcing people to think about subclassing more. It will just add confusing
boilerplate.

Things like Swift optionals work well because they make the (often
forgotten) choices explicit in the context that they are used. In the world
of Human Factors, we call it a forcing function. This proposal has the
inverse structure, and will be ineffective, because the “forcing” part of it
shows up in a different context (i.e. trying to use a framework) than the
decision is being made in (writing the framework). This type of thinking
leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I
predict this proposal would not only fail in increasing framework quality,
but also will make it much harder for users of those frameworks to work
around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about
their design would have been anyway. Those who are not thoughtful about
their design will just leave these annotations off… leaving us with no
recourse to extend/modify classes. When people complain, they will add the
annotations without actually thinking about the meaning (i.e. stack overflow
/ the fixit tells me I need to add this word to make the compiler happy).
All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.
If we truly want to solve the issue of subclassing, we need to consider all
of the common issues which arise. Looking at the cocoa documentation you
will see several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I
would like to see things be extendable by default, but with annotations that
thoughtful framework designers can use to designate how a particular method
should be used. In most cases, it should not explicitly forbid the end user
from subclassing, but require them to acknowledge that what they are doing
is not intended by the framework. (e.g. "unsafe override func"…). That
would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to
Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into
this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
while failing to achieve its objective. It goes against the retroactive
modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other
languages that lock things down, there is a need to unlock things soon after
(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking
for the ability to patch/override in cases where the framework designer was
wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access
control that touched on this subject as well. I have been designing
frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #5

Goffredo, sorry if it felt offensive. It was not my intention. I've dealt with so many different libraries where, as many already pointed out here, has to rely on "fixing" the library themselves. This is not what a library was supposed to be and I might have left a few of my bad experiences speak louder.

L

···

-----Original Message-----
From: "Goffredo Marocchi" <panajev@gmail.com>
Sent: ‎07/‎07/‎2016 01:39 PM
To: "Leonardo Pessoa" <me@lmpessoa.com>
Cc: "Jean-Daniel Dupas" <mailing@xenonium.com>; "swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P.

Seriously though

Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries.

this kind of attitude on this list got to stop.

Sent from my iPhone

On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override

arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other

times to workaround bugs in the library. Or even to extends the library in a

way that the author did not intent in the first place, but that was

perfectly supported anyway.

I already see how libraries author will react to that new default. They will

either don’t care and mark all classes as subclassable, or find to

burdensome to get subclassability right and prohibit subclassing all

classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which

something will need to be extended. You think you know, but are then

surprised by creative uses. My favorite features of Swift/Cocoa involve

retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of

forcing people to think about subclassing more. It will just add confusing

boilerplate.

Things like Swift optionals work well because they make the (often

forgotten) choices explicit in the context that they are used. In the world

of Human Factors, we call it a forcing function. This proposal has the

inverse structure, and will be ineffective, because the “forcing” part of it

shows up in a different context (i.e. trying to use a framework) than the

decision is being made in (writing the framework). This type of thinking

leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I

predict this proposal would not only fail in increasing framework quality,

but also will make it much harder for users of those frameworks to work

around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about

their design would have been anyway. Those who are not thoughtful about

their design will just leave these annotations off… leaving us with no

recourse to extend/modify classes. When people complain, they will add the

annotations without actually thinking about the meaning (i.e. stack overflow

/ the fixit tells me I need to add this word to make the compiler happy).

All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.

If we truly want to solve the issue of subclassing, we need to consider all

of the common issues which arise. Looking at the cocoa documentation you

will see several types of annotations:

1) This method MUST be overridden

2) This method should NOT be overridden

3) This method MUST be called

3) This method should NOT be called except by subclasses

4) This method should NOT be called except by a method override calling

super

5) This method MUST call super

6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I

would like to see things be extendable by default, but with annotations that

thoughtful framework designers can use to designate how a particular method

should be used. In most cases, it should not explicitly forbid the end user

from subclassing, but require them to acknowledge that what they are doing

is not intended by the framework. (e.g. "unsafe override func"…). That

would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to

Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into

this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate

while failing to achieve its objective. It goes against the retroactive

modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how

do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other

languages that lock things down, there is a need to unlock things soon after

(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking

for the ability to patch/override in cases where the framework designer was

wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,

or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access

control that touched on this subject as well. I have been designing

frameworks for years.

Thanks,

Jon

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

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(John McCall) #6

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P.

Making classes harder to work with is not a specific goal, no. :slight_smile:

I don't expect that this will be a significant burden for most Swift programmers. Mainly, that's because this only affects classes that are exposed outside of a module, and the great majority of non-system classes in a typical Cocoa program are single-purpose leaf classes that — at most — expose a few methods to other subsystems. Swift doesn't really encourage you write complex classes that are primarily customized with subclassing; it encourages the heavy use of value types, and it encourages customization through protocols and functions. In fact, that's not really new to Swift, it's a general lesson from the last few decades of software development: composing smaller, independent systems through well-defined interfaces leads to better software than building monolithic systems whose behavior can only be defined in reference to the whole.

I sympathize with the argument about wanting to fix bugs and add features via override, but that's never been maintainable in the long term; you always just end up with superclasses that everyone is terrified to touch because every subclass has its own invasive "fixes", and that's even when working within a single codebase. With libraries, you can pretty quickly get locked in to a specific version because your customizations don't work with new releases; either that, or the maintainer just decides that they can't fix of their mistakes and so goes off to rewrite it from scratch. Either way, it's not good for the ecosystem.

Plus, as others have mentioned, Swift already provides a lot of features that don't allow overriding: structs, final, etc. You simply cannot rely on overriding to fix upstream bugs the way that you can in most traditional OO languages because not enough code flows through calls to overridable methods. We should not compromise the goal of promoting stronger and more maintainable library designs just to maintain this illusion.

John.

···

n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Seriously though

Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries.

this kind of attitude on this list got to stop.

Sent from my iPhone

On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override
arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other
times to workaround bugs in the library. Or even to extends the library in a
way that the author did not intent in the first place, but that was
perfectly supported anyway.

I already see how libraries author will react to that new default. They will
either don’t care and mark all classes as subclassable, or find to
burdensome to get subclassability right and prohibit subclassing all
classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which
something will need to be extended. You think you know, but are then
surprised by creative uses. My favorite features of Swift/Cocoa involve
retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of
forcing people to think about subclassing more. It will just add confusing
boilerplate.

Things like Swift optionals work well because they make the (often
forgotten) choices explicit in the context that they are used. In the world
of Human Factors, we call it a forcing function. This proposal has the
inverse structure, and will be ineffective, because the “forcing” part of it
shows up in a different context (i.e. trying to use a framework) than the
decision is being made in (writing the framework). This type of thinking
leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I
predict this proposal would not only fail in increasing framework quality,
but also will make it much harder for users of those frameworks to work
around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about
their design would have been anyway. Those who are not thoughtful about
their design will just leave these annotations off… leaving us with no
recourse to extend/modify classes. When people complain, they will add the
annotations without actually thinking about the meaning (i.e. stack overflow
/ the fixit tells me I need to add this word to make the compiler happy).
All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.
If we truly want to solve the issue of subclassing, we need to consider all
of the common issues which arise. Looking at the cocoa documentation you
will see several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I
would like to see things be extendable by default, but with annotations that
thoughtful framework designers can use to designate how a particular method
should be used. In most cases, it should not explicitly forbid the end user
from subclassing, but require them to acknowledge that what they are doing
is not intended by the framework. (e.g. "unsafe override func"…). That
would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to
Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into
this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
while failing to achieve its objective. It goes against the retroactive
modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other
languages that lock things down, there is a need to unlock things soon after
(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking
for the ability to patch/override in cases where the framework designer was
wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access
control that touched on this subject as well. I have been designing
frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Goffredo Marocchi) #7

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P.

Seriously though

Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries.

this kind of attitude on this list got to stop.

···

Sent from my iPhone

On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override
arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other
times to workaround bugs in the library. Or even to extends the library in a
way that the author did not intent in the first place, but that was
perfectly supported anyway.

I already see how libraries author will react to that new default. They will
either don’t care and mark all classes as subclassable, or find to
burdensome to get subclassability right and prohibit subclassing all
classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution >> <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which
something will need to be extended. You think you know, but are then
surprised by creative uses. My favorite features of Swift/Cocoa involve
retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of
forcing people to think about subclassing more. It will just add confusing
boilerplate.

Things like Swift optionals work well because they make the (often
forgotten) choices explicit in the context that they are used. In the world
of Human Factors, we call it a forcing function. This proposal has the
inverse structure, and will be ineffective, because the “forcing” part of it
shows up in a different context (i.e. trying to use a framework) than the
decision is being made in (writing the framework). This type of thinking
leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I
predict this proposal would not only fail in increasing framework quality,
but also will make it much harder for users of those frameworks to work
around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about
their design would have been anyway. Those who are not thoughtful about
their design will just leave these annotations off… leaving us with no
recourse to extend/modify classes. When people complain, they will add the
annotations without actually thinking about the meaning (i.e. stack overflow
/ the fixit tells me I need to add this word to make the compiler happy).
All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.
If we truly want to solve the issue of subclassing, we need to consider all
of the common issues which arise. Looking at the cocoa documentation you
will see several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I
would like to see things be extendable by default, but with annotations that
thoughtful framework designers can use to designate how a particular method
should be used. In most cases, it should not explicitly forbid the end user
from subclassing, but require them to acknowledge that what they are doing
is not intended by the framework. (e.g. "unsafe override func"…). That
would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to
Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into
this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
while failing to achieve its objective. It goes against the retroactive
modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other
languages that lock things down, there is a need to unlock things soon after
(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking
for the ability to patch/override in cases where the framework designer was
wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access
control that touched on this subject as well. I have been designing
frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jean-Daniel) #8

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries.

If you consider Cocoa and other Apple frameworks as poorly design, then I guess you’re right…

Nonetheless, being able to subclass any class allowed me to solve a bunch of very bad memory leaks in the new NSCollectionView implementation, and made it usable for my project.

Thinking than you will have to work only with perfectly design libraries without any bug is utopian.
And thinking you can predict every usages of your library by users is short sighted IMHO.

···

Le 7 juil. 2016 à 18:23, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> a écrit :

By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override
arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other
times to workaround bugs in the library. Or even to extends the library in a
way that the author did not intent in the first place, but that was
perfectly supported anyway.

I already see how libraries author will react to that new default. They will
either don’t care and mark all classes as subclassable, or find to
burdensome to get subclassability right and prohibit subclassing all
classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution >> <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which
something will need to be extended. You think you know, but are then
surprised by creative uses. My favorite features of Swift/Cocoa involve
retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of
forcing people to think about subclassing more. It will just add confusing
boilerplate.

Things like Swift optionals work well because they make the (often
forgotten) choices explicit in the context that they are used. In the world
of Human Factors, we call it a forcing function. This proposal has the
inverse structure, and will be ineffective, because the “forcing” part of it
shows up in a different context (i.e. trying to use a framework) than the
decision is being made in (writing the framework). This type of thinking
leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I
predict this proposal would not only fail in increasing framework quality,
but also will make it much harder for users of those frameworks to work
around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about
their design would have been anyway. Those who are not thoughtful about
their design will just leave these annotations off… leaving us with no
recourse to extend/modify classes. When people complain, they will add the
annotations without actually thinking about the meaning (i.e. stack overflow
/ the fixit tells me I need to add this word to make the compiler happy).
All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.
If we truly want to solve the issue of subclassing, we need to consider all
of the common issues which arise. Looking at the cocoa documentation you
will see several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I
would like to see things be extendable by default, but with annotations that
thoughtful framework designers can use to designate how a particular method
should be used. In most cases, it should not explicitly forbid the end user
from subclassing, but require them to acknowledge that what they are doing
is not intended by the framework. (e.g. "unsafe override func"…). That
would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to
Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into
this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
while failing to achieve its objective. It goes against the retroactive
modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other
languages that lock things down, there is a need to unlock things soon after
(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking
for the ability to patch/override in cases where the framework designer was
wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access
control that touched on this subject as well. I have been designing
frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(L Mihalkovic) #9

Regards
(From mobile)

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all.

That is a grotesque depiction.

I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

If one does not have the patience to review one's own work to increase its quality, and would instead prefer to hand off the responsibility of finishing writing it to the compiler (i.e. making the compiler lock things down to avoid having to type "final"), perhaps a happier solution for everyone might be easier to keep this work private?
I noticed in recent years that the quality of some open source code has gone down, seemingly under the social pressure of having to be "one of the kool-ones" with code hanging in the breeze on github. Personally I don't mind if less code makes its way to github because it is more difficult to finish it properly.

···

On Jul 7, 2016, at 6:23 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution > <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override
arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other
times to workaround bugs in the library. Or even to extends the library in a
way that the author did not intent in the first place, but that was
perfectly supported anyway.

I already see how libraries author will react to that new default. They will
either don’t care and mark all classes as subclassable, or find to
burdensome to get subclassability right and prohibit subclassing all
classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution >> <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which
something will need to be extended. You think you know, but are then
surprised by creative uses. My favorite features of Swift/Cocoa involve
retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of
forcing people to think about subclassing more. It will just add confusing
boilerplate.

Things like Swift optionals work well because they make the (often
forgotten) choices explicit in the context that they are used. In the world
of Human Factors, we call it a forcing function. This proposal has the
inverse structure, and will be ineffective, because the “forcing” part of it
shows up in a different context (i.e. trying to use a framework) than the
decision is being made in (writing the framework). This type of thinking
leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I
predict this proposal would not only fail in increasing framework quality,
but also will make it much harder for users of those frameworks to work
around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about
their design would have been anyway. Those who are not thoughtful about
their design will just leave these annotations off… leaving us with no
recourse to extend/modify classes. When people complain, they will add the
annotations without actually thinking about the meaning (i.e. stack overflow
/ the fixit tells me I need to add this word to make the compiler happy).
All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.
If we truly want to solve the issue of subclassing, we need to consider all
of the common issues which arise. Looking at the cocoa documentation you
will see several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I
would like to see things be extendable by default, but with annotations that
thoughtful framework designers can use to designate how a particular method
should be used. In most cases, it should not explicitly forbid the end user
from subclassing, but require them to acknowledge that what they are doing
is not intended by the framework. (e.g. "unsafe override func"…). That
would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to
Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into
this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
while failing to achieve its objective. It goes against the retroactive
modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other
languages that lock things down, there is a need to unlock things soon after
(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking
for the ability to patch/override in cases where the framework designer was
wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access
control that touched on this subject as well. I have been designing
frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #10

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P.

Making classes harder to work with is not a specific goal, no. :slight_smile:

I don't expect that this will be a significant burden for most Swift programmers. Mainly, that's because this only affects classes that are exposed outside of a module, and the great majority of non-system classes in a typical Cocoa program are single-purpose leaf classes that — at most — expose a few methods to other subsystems. Swift doesn't really encourage you write complex classes that are primarily customized with subclassing; it encourages the heavy use of value types, and it encourages customization through protocols and functions. In fact, that's not really new to Swift, it's a general lesson from the last few decades of software development: composing smaller, independent systems through well-defined interfaces leads to better software than building monolithic systems whose behavior can only be defined in reference to the whole.

I sympathize with the argument about wanting to fix bugs and add features via override, but that's never been maintainable in the long term; you always just end up with superclasses that everyone is terrified to touch because every subclass has its own invasive "fixes", and that's even when working within a single codebase. With libraries, you can pretty quickly get locked in to a specific version because your customizations don't work with new releases; either that, or the maintainer just decides that they can't fix of their mistakes and so goes off to rewrite it from scratch. Either way, it's not good for the ecosystem.

Plus, as others have mentioned, Swift already provides a lot of features that don't allow overriding: structs, final, etc. You simply cannot rely on overriding to fix upstream bugs the way that you can in most traditional OO languages because not enough code flows through calls to overridable methods. We should not compromise the goal of promoting stronger and more maintainable library designs just to maintain this illusion.

Thanks for continuing to make the case for this John. I really, really hope the core team will accept the proposal (with revisions - the problems with the keyword names are real).

It will clearly ruffle a lot of feathers but is worth doing in this case IMO. Especially since many commenters who are opposed do not seem to grasp a couple of crucial points:

1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes). This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.

2. There is no impact on users of Apple's Objective-C APIs (AFAICT).

In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting. It just tightens up an inconsistency in the language (the one area where public API contracts are not explicitly opted-in to).

-Matthew

···

Sent from my iPad

On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

John.

Seriously though

Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries.

this kind of attitude on this list got to stop.

Sent from my iPhone

On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution >>> <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override
arbitrary classes and methods.

Sometimes to simply add log point to understand how the API work. Other
times to workaround bugs in the library. Or even to extends the library in a
way that the author did not intent in the first place, but that was
perfectly supported anyway.

I already see how libraries author will react to that new default. They will
either don’t care and mark all classes as subclassable, or find to
burdensome to get subclassability right and prohibit subclassing all
classes.

Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution >>>> <swift-evolution@swift.org> a écrit :

* What is your evaluation of the proposal?

A **strong** -1

First, I have often found that you can’t always predict the way which
something will need to be extended. You think you know, but are then
surprised by creative uses. My favorite features of Swift/Cocoa involve
retroactive modeling.

Second, I don’t think this proposal will achieve its stated objective of
forcing people to think about subclassing more. It will just add confusing
boilerplate.

Things like Swift optionals work well because they make the (often
forgotten) choices explicit in the context that they are used. In the world
of Human Factors, we call it a forcing function. This proposal has the
inverse structure, and will be ineffective, because the “forcing” part of it
shows up in a different context (i.e. trying to use a framework) than the
decision is being made in (writing the framework). This type of thinking
leads to things like Java and the DMV.

As Tino said:

No matter what the defaults are, good libraries are hard to build, so I
predict this proposal would not only fail in increasing framework quality,
but also will make it much harder for users of those frameworks to work
around their flaws, which are just a natural part of every software.

I think he is right on here. Those who were prone to be thoughtful about
their design would have been anyway. Those who are not thoughtful about
their design will just leave these annotations off… leaving us with no
recourse to extend/modify classes. When people complain, they will add the
annotations without actually thinking about the meaning (i.e. stack overflow
/ the fixit tells me I need to add this word to make the compiler happy).
All this does is put framework users at the mercy of the framework writers.

Finally, this proposal is missing important aspects of the problem space.
If we truly want to solve the issue of subclassing, we need to consider all
of the common issues which arise. Looking at the cocoa documentation you
will see several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I
would like to see things be extendable by default, but with annotations that
thoughtful framework designers can use to designate how a particular method
should be used. In most cases, it should not explicitly forbid the end user
from subclassing, but require them to acknowledge that what they are doing
is not intended by the framework. (e.g. "unsafe override func"…). That
would feel 1000x more swifty to me. Opt-out safety.

* Is the problem being addressed significant enough to warrant a change to
Swift?

No. It doesn’t actually solve the problem... and I haven’t actually run into
this problem in the real world.

* Does this proposal fit well with the feel and direction of Swift?

No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
while failing to achieve its objective. It goes against the retroactive
modeling allowed by other areas of Swift.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I tend to avoid languages which require this sort of thing. In other
languages that lock things down, there is a need to unlock things soon after
(e.g. friend classes).

I predict the same thing will happen here. People will quickly be asking
for the ability to patch/override in cases where the framework designer was
wrong. That shows a problem inherent with the design...

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal & discussion. Read earlier discussions around access
control that touched on this subject as well. I have been designing
frameworks for years.

Thanks,
Jon

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(John McCall) #11

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P.

Making classes harder to work with is not a specific goal, no. :slight_smile:

(Goffredo accidentally responded to me privately. With his permission, I'm reposting our brief side-conversation to the list.)

Is it just a "sweet oh so sweet" side-effect ;)?

Believe it or not, we do not actually have anything against classes! :slight_smile:

I don't expect that this will be a significant burden for most Swift programmers. Mainly, that's because this only affects classes that are exposed outside of a module, and the great majority of non-system classes in a typical Cocoa program are single-purpose leaf classes that — at most — expose a few methods to other subsystems. Swift doesn't really encourage you write complex classes that are primarily customized with subclassing; it encourages the heavy use of value types, and it encourages customization through protocols and functions. In fact, that's not really new to Swift, it's a general lesson from the last few decades of software development: composing smaller, independent systems through well-defined interfaces leads to better software than building monolithic systems whose behavior can only be defined in reference to the whole.

I sympathize with the argument about wanting to fix bugs and add features via override, but that's never been maintainable in the long term; you always just end up with superclasses that everyone is terrified to touch because every subclass has its own invasive "fixes", and that's even when working within a single codebase. With libraries, you can pretty quickly get locked in to a specific version because your customizations don't work with new releases; either that, or the maintainer just decides that they can't fix of their mistakes and so goes off to rewrite it from scratch. Either way, it's not good for the ecosystem.

Plus, as others have mentioned, Swift already provides a lot of features that don't allow overriding: structs, final, etc. You simply cannot rely on overriding to fix upstream bugs the way that you can in most traditional OO languages because not enough code flows through calls to overridable methods. We should not compromise the goal of promoting stronger and more maintainable library designs just to maintain this illusion.

John.

Thank you for taking the time to write out this detailed defense of your position. I appreciate it a lot :)!
I think that the issue, as evidenced in this thread too, is that library authors belief that sealing by default will bring ease of use AND a lot more safety at the same time while I fear this may make the language more complex actually.

I'm not going to deny that making classes non-subclassable by default outside of their module adds some complexity. However, that additional complexity is subject to "progressive disclosure": it only matters to people making classes part of their public interface, and only when they actually want to allow subclasses. Moreover, if they do want to allow subclasses, they'll try it and immediately run into the compiler error, which they can look up and hopefully find some good documentation on how to think about designing a class for subclassing. That's a pretty gentle prod.

I tend to prefer opt-in strategies, giving coders/people a better/safer alternative and allowing them to choose it instead of trying to babyproof everything/protect coders from themselves leaving them few ways to move out of the compiler imposed restrictions. It is easier and more scalable to figure out what to ban than what to allow (and assume everything we do not think of in advance is bad and ought to be banned)... but now I am going too much off a tangent... sorry.

This could easily be an argument for public-by-default. After all, internal-by-default is just protecting programmers from a mistake. Some libraries end up with "public" written absolutely everywhere, which seems silly and unnecessary. The rule promotes hiding a lot things from the user, but maybe those things would actually be really useful if they were exposed. Aren't we just babying the programmer? Is this restriction really worth anything? Maybe it would be easier to just make everything public by default and require programmers to explicitly hide everything they want to protect.

And you know, that's not a completely unreasonable way to approach some kinds of programming. If you're rapidly spinning up a prototype, you should not be obsessing about its software architecture, as long as you leave yourself room to think about it later (like, you know, when someone else starts depending on you). But the thing is, the things that work well when you're hacking on a demo are not the things that work well when you're designing an API that you hope to be supporting for a while. You really should be explicit about the things you want to expose to your clients. You really should think carefully about the places you want to allow code injection. And it makes sense for the language to flip some of its rules around at that library boundary to reflect the very different nature of the work.

John.

···

On Jul 7, 2016, at 4:16 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
On Thu, Jul 7, 2016 at 11:15 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:


(Tino) #12

1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes). This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.

2. There is no impact on users of Apple's Objective-C APIs (AFAICT).

In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting.

It is dramatic, and your whole argument is flawed because you miss the imho most important point.
This is not only a question of "will I be able to override this tiny method of UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by default", the direct impact is marginal as well — but it is a drastic change for the society as a whole.

Defaults matter, because they transmit a message:
Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.
When you use a library in a way that wasn't anticipated by its author, you'll ran into issues occasionally; nonetheless, I think we should struggle for an open ecosystem that encourages others to experiment and fail, rather than to limit their possibilities in a futile attempt to protect them.

Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?
As a matter of fact, open by default forces nobody to subclass and override, so it's easy to avoid any problems caused by excessive hacking — closed by default, on the other hand, has impact not only on those who believe in restrictions, but on those who dislike them as well.


(Rod Brown) #13

* What is your evaluation of this proposal?

A reluctant +1. I’m reluctant because I actually do love the flexibility in Obj-C to subclass where I feel appropriate, and feel the limitations of this are going to be difficult to get used to.

From what I see, however, “final” as a concept makes this more compelling. Being able to retroactively add final to a class is a great benefit for libraries, and this won’t be possible if we allow subclassing by default. Additionally, designing for subclassing is important and really should be considered at design time. I also think we need to flesh out the subclassing in this proposal where there are requirements to the override etc, but I agree in general with this concept.

* Is the problem being addressed significant enough to warrant a change to Swift?

There are multiple problems that this addresses. A change is definitely needed here to resolve them, whatever the form these changes take.

* Does this proposal fit well with the feel and direction of Swift?

Clarity at requirements for subclassing, and being more specific, seems in the 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?

I’ve used plenty of languages with subclassing, focusing most on Obj-C. I love the freedom to subclass in this language, but it’s fair that this is not the safest practice. Obj-C seems to be the wild west for subclassing.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve read the proposal, followed the conversation, and was involved in the first discussions about this earlier in the year.


(Matthew Johnson) #14

1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes). This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.

2. There is no impact on users of Apple's Objective-C APIs (AFAICT).

In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting.

It is dramatic, and your whole argument is flawed because you miss the imho most important point.

I didn't say it isn't dramatic, only that it isn't as dramatic a change as some commenters seem to suggest.

This is not only a question of "will I be able to override this tiny method of UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by default", the direct impact is marginal as well — but it is a drastic change for the society as a whole.

It's not about guilt or innocence, or any kind of lenience or punishment.

It's mostly about whether we want to foster an ecosystem where public API contracts have been explicitly considered or not. There are some ancillary benefits as well but those are much less important.

Defaults matter, because they transmit a message:

I agree.

Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.
When you use a library in a way that wasn't anticipated by its author, you'll ran into issues occasionally; nonetheless, I think we should struggle for an open ecosystem that encourages others to experiment and fail, rather than to limit their possibilities in a futile attempt to protect them.

In a majority of cases today this openness is better fostered by Github than "anything goes" public API.

Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?

I really wish Objective-C had this feature from the start. I believe there would have been significant benefits to Apple's platforms and ecosystem. The reasons for believing (or not believing) this have been discussed in depth so there isn't a need to rehash them now.

As a matter of fact, open by default forces nobody to subclass and override, so it's easy to avoid any problems caused by excessive hacking — closed by default, on the other hand, has impact not only on those who believe in restrictions, but on those who dislike them as well.

Actually open by default has caused some very nontrivial difficulties for Apple's framework maintainers. We all pay the price for this whether we engage in such subclassing and overriding or not. I find that pretty unfortunate, especially for those of us who do find other ways to solve our problems.

-Matthew

···

Sent from my iPad

On Jul 8, 2016, at 12:30 PM, Tino Heth <2th@gmx.de> wrote:


(Paul Cantrell) #15

Defaults matter, because they transmit a message:
Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.

…or “we favor mindfulness over carelessness,” or “we favor static type safety over runtime bug discovery.”

There are many ways of recoloring that thought.

Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?

The correct question is:

When was the last time you thought, “I really wish the author of that library had thought carefully about where and how they expected people to extend it?”

I spend a lot of time in the Ruby world as well, where there is no static type safety at all, and the entire type structure of your program and all of its libraries is open for rewiring the whole time the program is running. And you know what? It works just fine in practice! I’d say it favors rapid prototyping at the expense of subtle bugs staying hidden longer than they otherwise might. That’s a tradeoff that’s worth it for many projects. Pros and cons aside, though, people build good software this way. Ruby’s “nothing is sealed, everything is Play-Doh” approach really does work in practice.

The interesting question is not _whether_ this works, but _why_ it works. Ruby coders know not to expect any correctness help from the compiler, and know what kinds of testing they need to do to verify that correctness by other means. They build systems with the expectation of unit correctness being no guarantee of integrated system correctness. An entire ecosystem of culture, habit, and expectations supports the language’s looseness.

Swift already — today, right now, even without this proposal — sets very different expectations. Developers _do_ expect certain kinds of help from the compiler. In particular, they expect that consequential design decisions are explicitly declared, and that where is is a default, it is the one that favors static verification. Subclassibility is a consequential design decision, and it is one that precludes certain kinds of static verification (because how overriding methods can break encapsulation). Making it the default thus contradicts the developer expectations that the language has already established.

The question is not whether sealed or open is the One True Way. The question is which fits into Swift’s particular ecosystem of culture, habit, and expectations.

This is engineering, folks. No gospel truths here; it’s all tradeoffs. Open by default can be the right tradeoff for one language, and the wrong one for another.

Cheers,

Paul

···

On Jul 8, 2016, at 12:30 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:


(Leonardo Pessoa) #16

Just to relax a bit, from reading this thread I cannot help but feel a
relation to Civil War. One can even say on which side everyone here
would stand for real. #TeamIronMan

L

···

On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On Jul 8, 2016, at 12:30 PM, Tino Heth <2th@gmx.de> wrote:

1. As you point out, the majority of the surface area of idiomatic Swift
APIs are unlikely to be impacted (value types, protocols, and final
classes). This is very likely to apply to future Swift-native APIs from
Apple regardless of the outcome of this proposal.

2. There is no impact on users of Apple's Objective-C APIs (AFAICT).

In the context of these facts, this proposal is not nearly as dramatic a
change as many seem to be suggesting.

It is dramatic, and your whole argument is flawed because you miss the imho
most important point.

I didn't say it isn't dramatic, only that it isn't as dramatic a change as
some commenters seem to suggest.

This is not only a question of "will I be able to override this tiny method
of UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by
default", the direct impact is marginal as well — but it is a drastic change
for the society as a whole.

It's not about guilt or innocence, or any kind of lenience or punishment.

It's mostly about whether we want to foster an ecosystem where public API
contracts have been explicitly considered or not. There are some ancillary
benefits as well but those are much less important.

Defaults matter, because they transmit a message:

I agree.

Every rule and obstacle we add to Swift is a statement that says "we favor
bureaucracy over freedom", and this will affect the community evolving
around the language.
When you use a library in a way that wasn't anticipated by its author,
you'll ran into issues occasionally; nonetheless, I think we should struggle
for an open ecosystem that encourages others to experiment and fail, rather
than to limit their possibilities in a futile attempt to protect them.

In a majority of cases today this openness is better fostered by Github than
"anything goes" public API.

Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that
library had restricted my options to use it"?

I really wish Objective-C had this feature from the start. I believe there
would have been significant benefits to Apple's platforms and ecosystem.
The reasons for believing (or not believing) this have been discussed in
depth so there isn't a need to rehash them now.

As a matter of fact, open by default forces nobody to subclass and override,
so it's easy to avoid any problems caused by excessive hacking — closed by
default, on the other hand, has impact not only on those who believe in
restrictions, but on those who dislike them as well.

Actually open by default has caused some very nontrivial difficulties for
Apple's framework maintainers. We all pay the price for this whether we
engage in such subclassing and overriding or not. I find that pretty
unfortunate, especially for those of us who do find other ways to solve our
problems.

-Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Goffredo Marocchi) #17

You are correct that this is not a very agile - people over processes - move.

···

Sent from my iPhone

On 8 Jul 2016, at 18:30, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes). This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.

2. There is no impact on users of Apple's Objective-C APIs (AFAICT).

In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting.

It is dramatic, and your whole argument is flawed because you miss the imho most important point.
This is not only a question of "will I be able to override this tiny method of UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by default", the direct impact is marginal as well — but it is a drastic change for the society as a whole.

Defaults matter, because they transmit a message:
Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.
When you use a library in a way that wasn't anticipated by its author, you'll ran into issues occasionally; nonetheless, I think we should struggle for an open ecosystem that encourages others to experiment and fail, rather than to limit their possibilities in a futile attempt to protect them.

Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?
As a matter of fact, open by default forces nobody to subclass and override, so it's easy to avoid any problems caused by excessive hacking — closed by default, on the other hand, has impact not only on those who believe in restrictions, but on those who dislike them as well.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #18

When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?

I really wish Objective-C had this feature from the start. I believe there would have been significant benefits to Apple's platforms and ecosystem. The reasons for believing (or not believing) this have been discussed in depth so there isn't a need to rehash them now.

I'm not asking for reasons but for a single persuasive example…

It is easy to claim that everything will be better if we add restrictions, but so far, I haven't heard of any real problems cause by the current defaults:
The motivation to change them is not because of actual experience, it's just the trendy opinion that inheritance is evil.


(Matthew Johnson) #19

The stories I’ve seen about things Apple’s frameworks need to deal with are another. I don’t have links handy but they shouldn’t be too hard to find for anyone interested in looking.

···

On Jul 8, 2016, at 4:21 PM, Leonardo Pessoa <me@lmpessoa.com> wrote:

I've sent one I currently have myself. Look back on the thread posts.

L

On 8 July 2016 at 18:14, Tino Heth via swift-evolution > <swift-evolution@swift.org> wrote:

When was the last time you you thought "I really wish the author of that
library had restricted my options to use it"?

I really wish Objective-C had this feature from the start. I believe there
would have been significant benefits to Apple's platforms and ecosystem.
The reasons for believing (or not believing) this have been discussed in
depth so there isn't a need to rehash them now.

I'm not asking for reasons but for a single persuasive example…

It is easy to claim that everything will be better if we add restrictions,
but so far, I haven't heard of any real problems cause by the current
defaults:
The motivation to change them is not because of actual experience, it's just
the trendy opinion that inheritance is evil.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #20

I've sent one I currently have myself. Look back on the thread posts.

L

···

On 8 July 2016 at 18:14, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

When was the last time you you thought "I really wish the author of that
library had restricted my options to use it"?

I really wish Objective-C had this feature from the start. I believe there
would have been significant benefits to Apple's platforms and ecosystem.
The reasons for believing (or not believing) this have been discussed in
depth so there isn't a need to rehash them now.

I'm not asking for reasons but for a single persuasive example…

It is easy to claim that everything will be better if we add restrictions,
but so far, I haven't heard of any real problems cause by the current
defaults:
The motivation to change them is not because of actual experience, it's just
the trendy opinion that inheritance is evil.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution