[swift-evolution] Proposal - Allow properties in Extensions

Matthew Johnson matthew at anandabits.com
Wed Dec 23 12:51:11 CST 2015

> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> On Dec 23, 2015, at 7:05 AM, Paul Cantrell <cantrell at pobox.com> wrote:
>> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list