[swift-evolution] 'Public' class visibility specifiers

[Dimitri Racordon]

I’d agree with the proposition of eliminating open.
It does look as an additional layer of complexity for a use case that is imho not so common.

On 20 Feb 2017, at 18:07, Vladimir.S via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:

On 20.02.2017 19:47, Joanna Carter via swift-evolution wrote:
OK, here comes the girl with the big wooden spoon to stir things up a bit ;-)

When it comes to visibilities on classes, why, oh why do we have public vs open *as well as*
the option of marking stuff as final?

Surely, outside the module boundary :

1. public is the same as final ; i.e. you can see it but you can't derive from/override it

2. open is the same as public without final ; you can see it and derive from/override it

Inside the module boundary, there is essentially no difference between public and open.

In fact, open/public is a conflation of concerns.

Both allow public visibility but, mixed in with that is restriction of inheritance. Surely public is good enough for visibility and final is good enough for inheritance restriction?

////////////////
// Module1 file

// MARK: base classes

open class OpenClass
{
 open func test() { }
}

public class PublicClass
{
 public func test() { }

 public final func finalTest() { }
}

public final class FinalPublicClass
{
 public final func test() { }
}

// MARK: derived internal classes

class FrameworkDerivedPublicClass : PublicClass
{
 override func test() { }

 override func finalTest() { } // error : instance method overrides a 'final' instance method
}

class FrameworkDerivedFinalPublicClass : FinalPublicClass // error : inheritance from a final class
{
 override func test() { } // error : instance method overrides a 'final' instance method
}
///////////////

///////////////
// Module2 file

class OpenSubclass : OpenClass
{
 override func test() { }
}

class PublicSubclass : PublicClass // error : cannot inherit from non-open class 'PublicClass' outside of its defining module
{
 override func test() { } // error : overriding non-open instance method outside of its defining module

 override func finalTest() { } // error : method does not override any method from its superclass
}

class FinalPublicSubclass : FinalPublicClass // error : cannot inherit from non-open class 'FinalPublicClass' outside of its defining module
{
 override func test() { } // error : instance method overrides a 'final' instance method
                                          // error : overriding non-open instance method outside of its defining module
}
////////////////

In fact, the test() method in FinalPublicSubclass gives two errors one of which is the same as when declared in FrameworkDerivedFinalPublicClass.

If final is good enough for inside the module boundary, and the same "overriding final method" error appears in both places, do we really need this added complexity?

Surely, if we take public as meaning no inheritance control anywhere :

public class BaseClass
{
 public func test() { }

 public final func finalTest() { }
}

And then, either in or out of the module :

class DerivedClass : BaseClass
{
 override func test() { }

 override func finalTest() { } // error : instance method overrides a 'final' instance method
}

Or, if BaseClass were marked as final, then inheritance of the whole class is prohibited.

So, I am proposing a reduction in keywords from open, public and final, to just public and final.

With 'public' we can't have subtypes outside of the module, but can have subtypes inside the module. With 'final' you can't have subtype even inside module.
That was the main idea, that your module knows all the possible subtypes of some type.


--
Joanna Carter
Carter Consulting

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

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto: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/20170220/309a51d6/attachment.html>