[swift-evolution] Proposal - Allow properties in Extensions

[John McCall]

> On Dec 22, 2015, at 7:40 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> One potentially large downside is you can no longer look at a type declaration and find out how large it is. For example, I could define
>>>> 
>>>> struct Foo {
>>>> var x: Int
>>>> }
>>>> 
>>>> and it looks like a tiny struct, but I could then add an extension in a separate file that bloats that out to some ridiculously massive struct, and that wouldn't be obvious from looking at it.
>>> 
>>> I think any storage-in-extensions proposal ought to be a special feature of classes; I would not support the ability to add stored properties to structs in extensions, even from within the module.
>> 
>> I agree.
> 
> I don't see why any reasons that apply to classes wouldn't apply to structs: code organization, making the property private, etc. But maybe it should be called out explicitly with "@partial" or similar for structs.

Classes have identity.  To the extent that identity is important to a design, it has to be preserved; you can try to break up the object’s state into a bunch of different types, but if they all need to know about the same identity, you haven’t really done much except add complexity and (probably) retain cycles.  In other words, to the extent that a single object with identity is central to a design, it kindof makes sense for it to become a “god object”.  Usually we consider those bad in OO designs, with good reason, but those good reasons are often actually language failings that don’t necessarily apply in Swift.  The main one is encapsulation: 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.  (The only interesting language problem here here is allowing non-nullary initialization of the extensions, and that certainly seems solvable.)  Of course, in the places where identity *isn’t* important, it will generally make more sense to organize things by composition; but sometimes identity is important everywhere.

In contrast, since value types lack that inherent notion of identity, it seems much more likely to me that you just wouldn’t ever develop multiple sub-systems within a single type like that.  There’s certainly nothing pressuring you in that direction in the same way, at least that I can see.

John.