[swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[ilya]

Hello to all of the community.

*        * What is your evaluation of the proposal?*
+0.5
Agree on the motivation and 'public open class'
Let's discuss 'public open func' + application to dynamic runtime


*        * 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?*

My perspective is as follows.

We are designing a language that has a concept of classes and overrides.
Let's create a class and put some functions into it with the default
modifiers.

*Should it be possible to override those functions in the other parts of
the code?*

This is a deep question of language design. An answer will have profound
ramifications regarding the code that the compiler is allowed to produce.
It's not surprising that different languages give different answers:

- Java and Objective-C say "Yes"
- C++ and C# say "No"

Now, it doesn't look to me like it's "impossible to use libraries" in those
last two languages or that one has "less fun", or that they are
"disadvantaged on the server" because of their design choices.

What it looks like is a tradeoff. A freedom in one place is a requirement
in another place – if you say "one should be able to override those
methods", it means "a compiler should be required to perform virtual
dispatch on any call to those methods".

A smart compiler will be able to perform some guaranteed optimizations if
it knows that the calls can be devirtualized. This is a good thing, because
you can perfrom refactoring "for free".

As an example, in the scenario below Pyramid.computeVolume() can be
devirtualized even if you refactor this class as a subclass of an abstract
"Geometric-Body" class and make computeBase() overrideable.

    class Pyramid {
         func computeVolume() { return computeBase() * height / 3}
         func computeBase() { return π * radius * radius }
    }

This ability to extract away the code without the performance penalty and
without turning it into an unwanted override point is a benefit of the "No"
answer to the aforementioned question.

The ability to quickly design a hierarchy of classes without worrying first
about making them virtual is a benefit of the "Yes" answer to the
aforementioned question.

What would a good tradeoff then look like? It would combine the advantages
of both approaches. I believe that a default "Yes" answer within a module
and "No" across the boundary does that.

Therefore I feel like this proposal moves Swift in the right direction.

However, I'm not sure that 'open' is the right keyword for functions and
would prefer to see more discussion regarding it.

It's less clear what the benefits of non-open classes are in the dynamic
runtime, as we can't really promise that they will not be subclassed.
Incidentally, a lot of the criticism of the proposal touches the usage in
Swift of Cocoa Touch APIs. Maybe there is value in leaving things exactly
as they currently are in the Objective-C.

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

This is the first proposal I feel compelled to respond to.

Many interesting points regarding the proposal have been raised. I've spent
some time trying to read most of the thread and thought about this question
during a day. I also refreshed my memory regarding other languages, and the
design patterns of inheritance in general, e.g. here:

- https://codeblog.jonskeet.uk/2006/03/04/inheritancetax/
-
http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
- http://www.artima.com/intv/nonvirtualP.html
- http://stackoverflow.com/a/14451437/115200 (Eric Lippert)

Thank you if you got up to here,
Ilya.

On Sat, Jul 16, 2016 at 7:52 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> The second review of "SE-0117: Default classes to be non-subclassable
> publicly" begins now and runs through July 22. 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/3d110bfa/attachment.html>