-1 for the fact that if all devs can write working code, fewer can do it in a
clear structured fashion that is well designed for extensibility. A couple
months ago I even ran into difficulties when trying to extend AlamoFire because
some things had not been designed as cleanly as they could have been to make
extending it easy. So if the default is now that everything becomes
non-extensible but default, it is going to complicate (and partially defeat the
purpose of) reusing libraries.
Regards
(From mobile)
> On Jun 28, 2016, at 2:11 AM, Michael Ilseman via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I was also referring to how we present Objective-C classes in Swift. That is,
> if a Swift user tries to subclass an Objective-C-imported class, then we’d
> take into account sealed-ness in order to issue an error/warning, etc. If you
> are also proposing a Clang attribute for this, e.g. ‘swift_sealed’, to import
> as sealed (meaning issue an error if Swift users try to subclass it), then
> that should be spelled out as well. I don’t have an opinion on whether this
> is a good idea yet, just pointing out some more directions to explore. In
> general it feels like your proposal could use more fleshing out.
>
>
>> On Jun 27, 2016, at 5:08 PM, Javier Soto <javier....@gmail.com> wrote:
>>
>> That is a very good point, it should be explicitly mentioned in the
>> proposal. My thought would be that since in the Obj-C runtime it's not
>> possible to guarantee a class won't have subclasses, or that a method is not
>> overriden, Obj-C classes would be imported as open.
>>
>> On the Swift side, I think today it's possible to declare a "public final
>> @objc class", but you can still inherit from it from Obj-C, right? My hunch
>> would be that that should be disallowed, but perhaps there's a reason why
>> it's allowed today.
>> On Mon, Jun 27, 2016 at 4:25 PM Michael Ilseman <milse...@apple.com> wrote:
>>> Could you elaborate on how we should treat classes imported from
>>> Objective-C or CF-style C? That is, do we always annotate them as being
>>> “open” because those paradigms permit subclassing anywhere, or do you
>>> propose some kind of recommended “sealed” audit, or what?
>>>
>>>
>>>> On Jun 27, 2016, at 3:40 PM, Javier Soto via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>
>>>> Hello!
>>>>
>>>> I sent this as a PR on the swift-evolution repo, but we never had any
>>>> discussion about it on-list, besides a long time ago. Here's the first
>>>> draft of the proposal:
>>>>
>>>>
>>>> Sealed classes by default
>>>> Introduction
>>>>
>>>> Introduce a new sealed class modifier that makes classes and methods final
>>>> outside of the module they're declared in, but non-final within the module.
>>>>
>>>> Motivation
>>>>
>>>> It is not uncommon to have a need for a reference type without needing
>>>> inheritance. Classes must be intentionally designed to be subclassable,
>>>> carefully deciding which methods are the override entry-points such that
>>>> the the behavior remains correct and subclasses respect the Liskov
>>>> substitution principle.
>>>> Defaulting to non-final allows the author of a class to accidentally leave
>>>> the visible methods open for overrides, even if they didn't carefully
>>>> consider this possibility.
>>>> Requiring that the author of a class mark a class as open is akin to
>>>> requiring symbols to be explicitly public: it ensures that a conscious
>>>> decision is made regarding whether the ability to subclass a class is part
>>>> of the API.
>>>> Proposed solution
>>>>
>>>> New sealed (actual name pending bike-shedding) class modifier for classes
>>>> and methods which marks them as only overridable within the module they're
>>>> declared in.
>>>> sealed becomes the default for classes and methods.
>>>> New open (actual name pending bike-shedding) class modifier to explicitly
>>>> mark a class or a method as overridable.
>>>> Detailed design
>>>>
>>>> Code Examples:
>>>>
>>>> /// ModuleA:
>>>>
>>>> /// This class is `sealed` by default.
>>>> /// This is equivalent to `sealed class SealedParentClass`
>>>> class SealedParentClass {
>>>> /// This method is `sealed` by default`.
>>>> func foo()
>>>>
>>>> /// This raises a compilation error: a method can't have a
>>>> "subclassability"
>>>> /// level higher than that of its class.
>>>> open func bar()
>>>>
>>>> /// The behavior of `final` methods remains unchanged.
>>>> final func baz()
>>>> }
>>>>
>>>> open class OpenParentClass {
>>>> /// This method is `sealed` by default`.
>>>> func foo()
>>>>
>>>> /// Overridable methods in an `open` class must be explicitly marked
>>>> as `open`.
>>>> open func bar()
>>>>
>>>> /// The behavior of a `final` method remains unchanged.
>>>> final func baz()
>>>> }
>>>>
>>>> /// The behavior of `final` classes remains unchanged.
>>>> final class FinalClass { }
>>>> /// ModuleB:
>>>>
>>>> import ModuleA
>>>>
>>>> /// This raises a compilation error: ParentClass is effectively `final`
>>>> from
>>>> /// this module's point of view.
>>>> class SubclassA : SealedParentClass { }
>>>>
>>>> /// This is allowed since `OpenParentClass` has been marked explicitly
>>>> `open`
>>>> class SubclassB : OpenParentClass {
>>>> /// This raises a compilation error: `OpenParentClass.foo` is
>>>> /// effectively `final` outside of `ModuleA`.
>>>> override func foo() { }
>>>>
>>>> /// This is allowed since `OpenParentClass.bar` is explicitly `open`.
>>>> override func bar() { }
>>>> }
>>>> Impact on existing code
>>>>
>>>> This would be a backwards-breaking change for all classes and methods that
>>>> are public and non-final, which code outside of their module has
>>>> overriden. Those classes/methods would fail to compile. Their superclass
>>>> would need to be changed to open.
>>>> Alternatives considered
>>>>
>>>> Defaulting to final instead: This would be comparable to Swift defaulting
>>>> to private, as opposed to internal. Just like internal is a better
>>>> trade-off, sealed by default also makes sure that getting started with
>>>> Swift, writing code within a module, doesn't require a lot of boilerplate,
>>>> and fighting against the compiler.
>>>> --
>>>> Javier Soto
>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> --
>> Javier Soto
>
> _______________________________________________
> 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
