A short example where I personally wanted a public-but-not-open protocol:
public protocol SubscriptParameterType {
// This property was needed to prevent the client from breaking
// the library by conforming to the protocol, but I'd like to
// keep it invisible for the client, or even better prevent the
// client from conforming to the protocol.
var parameter: Document.SubscriptParameter { get }
}
extension Document {
public enum SubscriptParameter {
case string(String)
case integer(Int)
}
}
extension String : SubscriptParameterType {
public var parameter: Document.SubscriptParameter {
return .string(self)
}
}
extension Int : SubscriptParameterType {
public var parameter: Document.SubscriptParameter {
return .integer(self)
}
}
// Somewhere inside the `Document` type
public subscript(firstKey: String, parameters: SubscriptParameterType...) ->
Value? { … }
That implementation enables more safe queries of my Document type like
document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than
document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key"].
--
Adrian Zubarev
Sent with Airmail
Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution
(swift-evolution@swift.org) schrieb:
On Feb 15, 2017, at 9:59 AM, Rien <r...@balancingrock.nl> wrote:
On 15 Feb 2017, at 16:45, Matthew Johnson <matt...@anandabits.com> wrote:
On Feb 15, 2017, at 9:35 AM, Rien <r...@balancingrock.nl> wrote:
On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution
<swift-evolution@swift.org> wrote:
On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution
<swift-evolution@swift.org> wrote:
On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution
<swift-evolution@swift.org> wrote:
Our philosophy in general, however, is to default to the behavior which
preserves the most flexibility for the library designer.
Actually, I thought the philosophy was to preserver type safety. When did that
change?
Also, when was the library designer prioritised ahead of the application
developer?
Both open and non-open classes are common, but we chose to give non-open
classes the `public` keyword because that's the flexibility-preserving option.
No it isn’t, it’s the flexibility restricting option. The consumer of an open
class can subclass it. The consumer of a public class cannot subclass it. How
is the second more flexible than the first?
It reduces complexity for the library author by allowing them to opt-out of the
complexity involved in supporting unknown, user-defined subclasses. It is
important to allow libraries to have this flexibility. They are free to declare
a class `open` if they want to allow subclassing. It’s even possibly for a
library to declare all classes `open` if it wishes to do so. But *requiring*
that would reduce the design space libraries are allowed to explore and / or
introduce fragility by moving the subclass restriction to a comment.
Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.
This is composition, not inheritance. The most important difference is that a
wrapper cannot override methods, it can only wrap and / or forward them. This
means that when the superclass calls a method on `self` that method *always*
invokes its version of that method rather than a subclass override. This is a
very important difference.
Agreed, however that does not answer the question why would a library developer
want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented
without it. (without “open”)
The feature it enables is more robust libraries and the ability for library
authors to better reason about their code. You may not find this benefit
enough to be worth a language feature, but many of us do.
Rien.
There are cases where subclassing does not make sense. And thus preventing
subclasses adds information for those users that don’t RTFM. But that imo is
not worth the impact extra complexity places on all other users.
Rien.
_______________________________________________
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
_______________________________________________
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
