Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

On Fri, Jul 15, 2016 at 2:26 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 14, 2016, at 10:58 PM, Charles Srstka > wrote: > > On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On 15 Jul 2016, at 12:46, Haravikk via swift-evolution > wrote: > > >> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution >> > wrote: >> >> To sum this all up, the core team is rejecting this

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

On Jul 15, 2016, at 9:36 AM, L. Mihalkovic wrote: >>> >>> Or because the framework was developed in the real world, rather than >>> Elysium, and real-world framework developers just about *never* anticipate >>> every single way someone might use their framework

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

Regards (From mobile) > On Jul 15, 2016, at 8:26 AM, Chris Lattner via swift-evolution > wrote: > > >>> On Jul 14, 2016, at 10:58 PM, Charles Srstka >>> wrote: >>> >>> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

I'll also stick with "open" for both class and methods and I believe they should be required for both too. Just as I may not design a class to be subclassable outside my library, I may not want to allow a method to be overriden outside the library either (but I may want to override it inside the

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution > wrote: > > To sum this all up, the core team is rejecting this proposal and requesting a > revision to change the concrete syntax to “public open class Foo” instead of > “subclassable class Foo".

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> does it make sense to require every member to be marked as “overridable” in > order to be overridden by an open subclass outside of the current module? Despite of probably being one of the most passionate defenders against adding restrictions on subclassing, I've to accept the clear

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

I have deliberately kept away from the discussion on this topic, as I didn’t feel like I can contribute in any meaningful way. In all honesty, I have barely used ‚traditional’ OOP paradigms in the last few years at all. While OOP is a useful tool and its great for modelling certain relationship

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 10:58 PM, Charles Srstka wrote: > >> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution >> > wrote: >> >> - Second is that clients of some other public API vended by a

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution > wrote: > > - Second is that clients of some other public API vended by a non-Apple > framework (e.g. a SwiftPM package) may end up in a situation where the > framework author didn’t consider

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 11:39 PM, Chris Lattner via swift-evolution > wrote: > > To sum this all up, the core team is rejecting this proposal and requesting a > revision to change the concrete syntax to “public open class Foo” instead of > “subclassable class Foo".