> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution > <swift-evolution@swift.org> 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. >
How would private initialization of extensions work? > John. > _______________________________________________ > 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
