> On Jul 8, 2016, at 23:47, L. Mihalkovic <laurent.mihalko...@gmail.com> wrote: > > > > Regards > (From mobile) > > On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
