> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > 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”]
I see how that makes queries better. However what I do not see is how making the protocol “open” would make this less safe. (I do not see a reason to make it open either, but that is not the question) It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?. Regards, Rien. > . > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution > ([email protected]) schrieb: > >> >>> On Feb 15, 2017, at 9:59 AM, Rien <[email protected]> wrote: >>> >>>> >>>> On 15 Feb 2017, at 16:45, Matthew Johnson <[email protected]> wrote: >>>> >>>>> >>>>> On Feb 15, 2017, at 9:35 AM, Rien <[email protected]> wrote: >>>>> >>>>> >>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >>>>>>>> <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
