Ah, the irony…
Having argued against too much complexity, I now encountered an error in my
software that shows why there might indeed be a need for “open” and “public”.
In an API:
class Foo {
open func foo(options: Option ...) {
foo(options)
}
open func foo(options: [Options]) { … }
}
An API user might do this:
class Bar: Foo {
override func foo(options: Option ...) {
…
super.foo(options)
}
}
var b = Bar()
b.foo(options: [Option.thisOne])
This compiles fine, and will even work .... up to a point where the additions
in Bar.foo are essential. Then it fails.
The user should have called: b.foo(options: Option.thisOne)
This can easily be prevented by making Foo.foo(options: Option) public instead
of open.
Then the user would not have been able to override the convenience method.
Furthermore: the user would not have experienced any inconvenience either as
Foo.foo() would still be usable.
The interesting thing is that in this case there is no real argument on the
side of the API developer to have a need for either open or public. It is
entirely to the benefit of the API user. To me that makes a case for having
both open and public. As an API developer I am willing to “go the extra mile”
to create a good user experience, even if that means using tricks to achieve
that end. However that would be impossible in this case. This end-user
convenience is only achievable through open and public.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
