[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jordan Rose]

> On Jul 8, 2016, at 23:47, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
> On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md <https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md> ]
>> 
>> John has done a tremendous job supporting this proposal; the position he’s articulated very closely matches mine. Thank you to both John and Javier. 
>> 
>> I wanted to share a concrete use case that Daniel Dunbar relayed to me. He was working on a closed class hierarchy like the ones discussed here, where all of the subclasses are within a single module, but they are all public. The class also has a required initializer for dynamic construction, so that they could write something like this:
>> 
>> internal struct ModelContext { /*…*/ }
>> 
>> public class ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>>   // …
>> }
>> public class SimpleModel: ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>> }
>> public class MoreComplicatedModel: ModelBase { /*…*/ }
>> 
>> // (within some other type)
>> public func instantiateModelObject<Model: ModelBase>(_ type: Model) -> Model {
>>   return type.init(context: self.context)
>> }
>> 
>> That is, a public entry point calls a required initializer with an internal argument type. This is the only way to instantiate Model objects, and the internal context type doesn’t leak out into the public API.
> 
> Then could it be that in the end it is the entire scaffolding that is poorly structured and in need of fixing, rather than altering the language to make the scaffolding work?

I’m afraid it isn’t my codebase, so I can’t speak to this directly, but I don’t see anything wrong with this pattern. Dynamic initialization is useful, and internal, component-specific context is hardly uncommon; if the library used either of these alone we would likely have no problem with it. Two features not composing well does sometimes indicate a flaw in the design.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160710/0c0c96ca/attachment.html>