> On Dec 23, 2015, at 12:50 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Dec 23, 2015, at 7:05 AM, Paul Cantrell <cantr...@pobox.com> wrote: >> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >>> >>> when you stuff a lot of functionality into a single class in most OO >>> languages, there’s no real way to enforce its division into subsystems, >>> because every method has direct access to every property and every other >>> method. In contrast, in Swift you can divide that class into distinct >>> components with their own interface, state, and invariants, essentially >>> making each component as good as its own type as far as encapsulation goes. >> >> Can you elaborate on this, John? Extensions and protocols in Swift today >> still don’t solve the problem that shared _private_ class state has to be >> centralized. Or were you speaking as if this “properties in extensions” >> proposal were already implemented? > > Yes, that’s right. I’m explaining why I think it makes sense to limit stored > instance properties in extensions to class types: especially with some > solution for private initialization of extensions, they enable intra-class > encapsulation in a way that matters for classes and not really for other > types.
OK, gotcha. It’s the “some solution for private initialization of extensions” part that’s missing. How do you imagine that playing out? If an extension can’t store a property, then what would “private initialization” mean? P _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution