Re: [swift-evolution] Proposal - Allow properties in Extensions
> I only see the benefits on this. > • We don't have to store all states in one file. States can be stored > separately. So, we can write code in more composition style. > • We can add new states to the existing type. Not just NSObject > subclass with associated object. I think people generally want this; the question is how to implement it, and especially how to implement it *without* either limiting it to types in the same module, or dangling what amounts to a dictionary off every single object and struct. (Structs are more difficult than objects, because they don’t have stable identities.) Any ideas? -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
I’d +1 this proposal for extensions existing in the same module as the class
declaration. However, creating new properties for classes defined in other
modules would likely involve side-table lookups, and my understanding is that
it has some performance implications.
In cases where you want to extend the storage of a class, consider if maybe a
subclass is all you need.
Dan
> On Dec 18, 2015, at 11:42 AM, Nutchaphon Rewik via swift-evolution
> wrote:
>
> I only see the benefits on this.
> We don't have to store all states in one file. States can be stored
> separately. So, we can write code in more composition style.
> We can add new states to the existing type. Not just NSObject subclass with
> associated object.
>
> protocol Incrementer{
> func increase()
> }
>
> extension Incrementer{
>
> var count = 1 // allows stored properties
>
> func increase(){
> print(count)
> count = count + 1
> }
>
> }
>
>
> > On Dec 8, 2015, at 10:51 AM, Kevin Kachikian via swift-evolution
> > > > wrote:
> >
> > I’d like to proposal to the Swift community and discuss the advantages and
> > disadvantages of adding modifiable properties to extensions (in addition to
> > the already existing computed properties, instance methods, subscripts,
> > etc.):
> >
> > extension SomeType {
> >
> > var aNewProperty: Int
> > var anotherVariable: String
> > var aThirdOne: MyStruct
> ___
> 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I only see the benefits on this. >> • We don't have to store all states in one file. States can be stored >> separately. So, we can write code in more composition style. >> • We can add new states to the existing type. Not just NSObject >> subclass with associated object. > > I think people generally want this; the question is how to implement it, and > especially how to implement it *without* either limiting it to types in the > same module, or dangling what amounts to a dictionary off every single object > and struct. (Structs are more difficult than objects, because they don’t have > stable identities.) Any ideas? You could say that types whose conformance to the protocol lives in the same module as the type itself get the default property storage, but external extensions that introduce the conformance can't use the default stored property and have to supply their own implementation. -Joe ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote:
>
> > On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution
> > wrote:
> >
> >> I only see the benefits on this.
> >>• We don't have to store all states in one file. States can be stored
> >> separately. So, we can write code in more composition style.
> >>• We can add new states to the existing type. Not just NSObject
> >> subclass with associated object.
> >
> > I think people generally want this; the question is how to implement it,
> > and especially how to implement it *without* either limiting it to types in
> > the same module, or dangling what amounts to a dictionary off every single
> > object and struct. (Structs are more difficult than objects, because they
> > don’t have stable identities.) Any ideas?
>
> You could say that types whose conformance to the protocol lives in the same
> module as the type itself get the default property storage, but external
> extensions that introduce the conformance can't use the default stored
> property and have to supply their own implementation.
AFAIK there's no precedent today for extensions in the same module being able
to do things that extensions in other modules can't do (beyond accessing
`internal` members of course). I'm not completely opposed to the idea, but I
would want to be very careful and make sure there's an extremely clear benefit
to changing it so extensions in the same module can add extra storage.
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.
That said, when looking at a definition imported from another module, you can't
see which properties are computed and which are stored anyway, so it's maybe
not a huge deal (although you can assume any property defined in an extension
is computed). But it is still something to consider.
-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution
> wrote:
>
> On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote:
>>
>>> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution
>>> wrote:
>>>
I only see the benefits on this.
• We don't have to store all states in one file. States can be stored
separately. So, we can write code in more composition style.
• We can add new states to the existing type. Not just NSObject
subclass with associated object.
>>>
>>> I think people generally want this; the question is how to implement it,
>>> and especially how to implement it *without* either limiting it to types in
>>> the same module, or dangling what amounts to a dictionary off every single
>>> object and struct. (Structs are more difficult than objects, because they
>>> don’t have stable identities.) Any ideas?
>>
>> You could say that types whose conformance to the protocol lives in the same
>> module as the type itself get the default property storage, but external
>> extensions that introduce the conformance can't use the default stored
>> property and have to supply their own implementation.
>
> AFAIK there's no precedent today for extensions in the same module being able
> to do things that extensions in other modules can't do (beyond accessing
> `internal` members of course). I'm not completely opposed to the idea, but I
> would want to be very careful and make sure there's an extremely clear
> benefit to changing it so extensions in the same module can add extra storage.
>
> 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.
>
> That said, when looking at a definition imported from another module, you
> can't see which properties are computed and which are stored anyway, so it's
> maybe not a huge deal (although you can assume any property defined in an
> extension is computed). But it is still something to consider.
True, this is a tradeoff. We've discussed moving in the direction of allowing
same-module extensions to do anything that can be done in the original type
declaration, to allow freedom of organization without arbitrary rules about
what must go in the type, but sizing instances was one of our concerns. (You
could always peek at the LLVM IR if you want to know for sure what's getting
generated.)
-Joe___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
I’m really glad to see some discussion about this. I think it is an extremely
worth while addition to Swift. Chris L. also thought it was a good idea, in
general.
If I get a chance I’ll make a formal request to consider it. Anyone else
interested in offering it up, officially?
Thanks,
Kevin Kachikian
> On Dec 18, 2015, at 11:42 AM, Nutchaphon Rewik wrote:
>
> I only see the benefits on this.
> We don't have to store all states in one file. States can be stored
> separately. So, we can write code in more composition style.
> We can add new states to the existing type. Not just NSObject subclass with
> associated object.
>
> protocol Incrementer{
> func increase()
> }
>
> extension Incrementer{
>
> var count = 1 // allows stored properties
>
> func increase(){
> print(count)
> count = count + 1
> }
>
> }
>
>
> > On Dec 8, 2015, at 10:51 AM, Kevin Kachikian via swift-evolution
> > > > wrote:
> >
> > I’d like to proposal to the Swift community and discuss the advantages and
> > disadvantages of adding modifiable properties to extensions (in addition to
> > the already existing computed properties, instance methods, subscripts,
> > etc.):
> >
> > extension SomeType {
> >
> > var aNewProperty: Int
> > var anotherVariable: String
> > var aThirdOne: MyStruct
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution
> wrote:
>
>
>> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> AFAIK there's no precedent today for extensions in the same module being
>> able to do things that extensions in other modules can't do (beyond
>> accessing `internal` members of course). I'm not completely opposed to the
>> idea, but I would want to be very careful and make sure there's an extremely
>> clear benefit to changing it so extensions in the same module can add extra
>> storage.
>>
>> 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.
>>
>> That said, when looking at a definition imported from another module, you
>> can't see which properties are computed and which are stored anyway, so it's
>> maybe not a huge deal (although you can assume any property defined in an
>> extension is computed). But it is still something to consider.
>
> True, this is a tradeoff. We've discussed moving in the direction of allowing
> same-module extensions to do anything that can be done in the original type
> declaration, to allow freedom of organization without arbitrary rules about
> what must go in the type, but sizing instances was one of our concerns. (You
> could always peek at the LLVM IR if you want to know for sure what's getting
> generated.)
Have you considered using “partial” or “extendable" for these types of
definitions (similar to C# partials) to reduce this confusion?
extendable struct Foo {
var x: Int
}
When the keyword is there, all bets are off that the layout of the struct only
contains a single member. Then extensions, defined within the same module,
could add to it.
-David___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution
> wrote:
> On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote:
>>
>>> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution
>>> wrote:
>>>
I only see the benefits on this.
• We don't have to store all states in one file. States can be stored
separately. So, we can write code in more composition style.
• We can add new states to the existing type. Not just NSObject
subclass with associated object.
>>>
>>> I think people generally want this; the question is how to implement it,
>>> and especially how to implement it *without* either limiting it to types in
>>> the same module, or dangling what amounts to a dictionary off every single
>>> object and struct. (Structs are more difficult than objects, because they
>>> don’t have stable identities.) Any ideas?
>>
>> You could say that types whose conformance to the protocol lives in the same
>> module as the type itself get the default property storage, but external
>> extensions that introduce the conformance can't use the default stored
>> property and have to supply their own implementation.
>
> AFAIK there's no precedent today for extensions in the same module being able
> to do things that extensions in other modules can't do (beyond accessing
> `internal` members of course). I'm not completely opposed to the idea, but I
> would want to be very careful and make sure there's an extremely clear
> benefit to changing it so extensions in the same module can add extra storage.
>
> 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.
John.
>
> That said, when looking at a definition imported from another module, you
> can't see which properties are computed and which are stored anyway, so it's
> maybe not a huge deal (although you can assume any property defined in an
> extension is computed). But it is still something to consider.
>
> -Kevin Ballard
> ___
> 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
+1 for "[giving] same-module extensions to do anything that can be done in
the original type declaration", +1 for something akin to C#'s 'partial'.
I've often wanted to organize my code for a single type within several
files, grouping methods and properties by purpose, but have been stymied by
both the way access control works and by the restriction on stored
properties.
Best,
Austin
On Fri, Dec 18, 2015 at 3:58 PM, David Owens II via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> AFAIK there's no precedent today for extensions in the same module being
> able to do things that extensions in other modules can't do (beyond
> accessing `internal` members of course). I'm not completely opposed to the
> idea, but I would want to be very careful and make sure there's an
> extremely clear benefit to changing it so extensions in the same module can
> add extra storage.
>
> 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.
>
> That said, when looking at a definition imported from another module, you
> can't see which properties are computed and which are stored anyway, so
> it's maybe not a huge deal (although you can assume any property defined in
> an extension is computed). But it is still something to consider.
>
>
> True, this is a tradeoff. We've discussed moving in the direction of
> allowing same-module extensions to do anything that can be done in the
> original type declaration, to allow freedom of organization without
> arbitrary rules about what must go in the type, but sizing instances was
> one of our concerns. (You could always peek at the LLVM IR if you want to
> know for sure what's getting generated.)
>
>
>
> Have you considered using “partial” or “extendable" for these types of
> definitions (similar to C# partials) to reduce this confusion?
>
> extendable struct Foo {
>var x: Int
> }
>
>
> When the keyword is there, all bets are off that the layout of the struct
> only contains a single member. Then extensions, defined within the same
> module, could add to it.
>
> -David
>
> ___
> 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: > 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. Oh that's an interesting idea. My immediate reaction to "I don't want unpredictable sizes" was upon reflection something that only applies to structs. Classes are reference types already, so adding storage to them doesn't really have much consequence (structs get copied around so their size is important). Not only that, but we can already use associated objects with classes, so adding proper stored properties to them doesn't actually change the semantics of extensions, it just means avoiding the overhead of associated objects (and of value wrappers for associated objects) when the extension is part of the same module. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: > On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: >> 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. > > Oh that's an interesting idea. My immediate reaction to "I don't want > unpredictable sizes" was upon reflection something that only applies to > structs. Classes are reference types already, so adding storage to them > doesn't really have much consequence (structs get copied around so their size > is important). Not only that, but we can already use associated objects with > classes, so adding proper stored properties to them doesn't actually change > the semantics of extensions, it just means avoiding the overhead of > associated objects (and of value wrappers for associated objects) when the > extension is part of the same module. Right. And I think we’d also want to support some way to explicitly request the out-of-line representation even within the module. John. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: > > On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: > > On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: > >> 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. > > > > Oh that's an interesting idea. My immediate reaction to "I don't want > > unpredictable sizes" was upon reflection something that only applies to > > structs. Classes are reference types already, so adding storage to them > > doesn't really have much consequence (structs get copied around so their > > size is important). Not only that, but we can already use associated > > objects with classes, so adding proper stored properties to them doesn't > > actually change the semantics of extensions, it just means avoiding the > > overhead of associated objects (and of value wrappers for associated > > objects) when the extension is part of the same module. > > Right. And I think we’d also want to support some way to explicitly request > the out-of-line representation even within the module. Property behaviors could do out-of-line storage for classes (assuming property behaviors retain the ability to get at the owning class, which is something I mentioned as being problematic in my review). You could technically do out-of-line storage for structs by having an inline storage of object type and then using the lifetime of that object to manage the out-of-line storage, but that doesn't seem particularly great and it also breaks value semantics. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution > wrote: > > On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: >>> On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: >>> On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: 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. >>> >>> Oh that's an interesting idea. My immediate reaction to "I don't want >>> unpredictable sizes" was upon reflection something that only applies to >>> structs. Classes are reference types already, so adding storage to them >>> doesn't really have much consequence (structs get copied around so their >>> size is important). Not only that, but we can already use associated >>> objects with classes, so adding proper stored properties to them doesn't >>> actually change the semantics of extensions, it just means avoiding the >>> overhead of associated objects (and of value wrappers for associated >>> objects) when the extension is part of the same module. >> >> Right. And I think we’d also want to support some way to explicitly request >> the out-of-line representation even within the module. > > Property behaviors could do out-of-line storage for classes (assuming > property behaviors retain the ability to get at the owning class, which is > something I mentioned as being problematic in my review). You could > technically do out-of-line storage for structs by having an inline storage of > object type and then using the lifetime of that object to manage the > out-of-line storage, but that doesn't seem particularly great and it also > breaks value semantics. A behavior should also be able to implement a copy-on-write policy on mutation in order to preserve value semantics in struct containers. -Joe___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution
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.
-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
On Fri, Dec 18, 2015, at 05:45 PM, Joe Groff wrote: > >> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: > 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. Oh that's an interesting idea. My immediate reaction to "I don't want unpredictable sizes" was upon reflection something that only applies to structs. Classes are reference types already, so adding storage to them doesn't really have much consequence (structs get copied around so their size is important). Not only that, but we can already use associated objects with classes, so adding proper stored properties to them doesn't actually change the semantics of extensions, it just means avoiding the overhead of associated objects (and of value wrappers for associated objects) when the extension is part of the same module. >>> >>> Right. And I think we’d also want to support some way to explicitly >>> request the out-of-line representation even within the module. >> >> Property behaviors could do out-of-line storage for classes (assuming >> property behaviors retain the ability to get at the owning class, >> which is something I mentioned as being problematic in my review). >> You could technically do out-of-line storage for structs by having an >> inline storage of object type and then using the lifetime of that >> object to manage the out-of-line storage, but that doesn't seem >> particularly great and it also breaks value semantics. > > A behavior should also be able to implement a copy-on-write policy on > mutation in order to preserve value semantics in struct containers. I suppose that's true, if a class is used for out-of-line storage then you can use the same uniqueness testing that the existing COW containers use. I was originally thinking about using it like associated objects, but it makes a lot more sense to use something like ManagedBuffer instead. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution
> wrote:
>
> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution
> 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.
Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 22, 2015, at 7:40 PM, Jordan Rose wrote:
>> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution
>> wrote:
>>
>> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution
>> 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
+1/-1: When the extension is in the same module, it's nice to be able to group all aspects of an extension in one place instead of being forced to declare properties in the definition. But I guess the most important use case is to extend types that aren't in the same module, and I wouldn't like to see that hacking the runtime becomes a common thing to do. Tino ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
I agree. I think stored properties in extensions should only be visible in its scope. If we combine the idea with scope access modifier ( https://github.com/apple/swift-evolution/pull/64 ). We can make the rule that no stored property is allowed to expose from its extension. Nutchaphon From: Tino Heth <2...@gmx.de> Sent: Wednesday, December 23, 2015 6:42 PM To: Nutchaphon Rewik Cc: ke...@mac.com; swift-evolution@swift.org Subject: Re: [swift-evolution] Proposal - Allow properties in Extensions +1/-1: When the extension is in the same module, it's nice to be able to group all aspects of an extension in one place instead of being forced to declare properties in the definition. But I guess the most important use case is to extend types that aren't in the same module, and I wouldn't like to see that hacking the runtime becomes a common thing to do. Tino ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
I like this proposal in theory. The idea of localizing a member declaration
inside the extension that actually uses that member certainly has advantages.
At the same time, I have concerns about allowing this.
In some ways it makes code less readable because it isn’t possible to see all
of the stored members of a type in one location. IDEs and generated
documentation can help with this, but the code itself suffers.
I am also concerned about how this would interact with initializers, especially
when the member is not provided with an initial value. Adding an extension
that declares a new stored property is likely to have non-local effects. If
you might already need to visit another file to update the initializers when
adding the member the value of allowing the member declaration to be elsewhere
is somewhat reduced.
The initialization concern can at least be mitigated to some degree by
providing an initial value and / or if we adopt the flexible memberwise
initialization proposal and all initializers for the type are able to
initialize the added member using memberwise initialization. That reduces the
concern but doesn’t completely eliminate it.
I think it would be worthwhile to carefully consider how allowing stored
properties in extensions interact with initializers in the wild. Is the value
they provide sufficient to outweigh any initialization complexities they might
introduce? Do we need to include restrictions on stored properties in
extensions in order to reduce those complexities (such as requiring an initial
value)?
Matthew
> On Dec 22, 2015, at 9:40 PM, Jordan Rose via swift-evolution
> wrote:
>
>
>> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution
>> wrote:
>>
>> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution
>> 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.
>
> Jordan
> ___
> 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution 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? Cheers, Paul ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
I wouldn't mind it being treated just as a bunch of getters and setters. On Wed, Dec 23, 2015 at 3:05 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> 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? > > Cheers, > > Paul > > ___ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Wizard ja...@supmenow.com +44 7523 279 698 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
I don’t think hacking the runtime is much of an issue, more that it might already be now. However part of the thinking behind the idea of extending extensions to encompass property declarations, above and beyond grouping related code together, is to maintain orthogonality: Structs and classes can declare properties and so should extensions to such types be able to as well. Kevin > On Dec 23, 2015, at 3:42 AM, Tino Heth <2...@gmx.de> wrote: > > +1/-1: > > When the extension is in the same module, it's nice to be able to group all > aspects of an extension in one place instead of being forced to declare > properties in the definition. > But I guess the most important use case is to extend types that aren't in the > same module, and I wouldn't like to see that hacking the runtime becomes a > common thing to do. > > Tino ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 23, 2015, at 10:02 AM, Kevin Kachikian via swift-evolution > wrote: > > I don’t think hacking the runtime is much of an issue, more that it might > already be now. > > However part of the thinking behind the idea of extending extensions to > encompass property declarations, above and beyond grouping related code > together, is to maintain orthogonality: Structs and classes can declare > properties and so should extensions to such types be able to as well. The problem I think we need to consider carefully is that introducing stored properties is not necessarily orthogonal. It can have significant impact on all initializers. > > Kevin > > >> On Dec 23, 2015, at 3:42 AM, Tino Heth <2...@gmx.de> wrote: >> >> +1/-1: >> >> When the extension is in the same module, it's nice to be able to group all >> aspects of an extension in one place instead of being forced to declare >> properties in the definition. >> But I guess the most important use case is to extend types that aren't in >> the same module, and I wouldn't like to see that hacking the runtime becomes >> a common thing to do. >> >> Tino > > ___ > 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote: > On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution > 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. John. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution > wrote: > >> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote: >> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution >> 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 23, 2015, at 12:50 PM, John McCall wrote: > >> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote: >> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution >> 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
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 23, 2015, at 10:51 AM, Matthew Johnson wrote:
>
>
>> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
>> wrote:
>>
>>> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote:
>>> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
>>> 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?
Just spit-balling, but something like:
class A {
init(numbers: [Int]) {
// Definitive initialization requires initialization of all the
extensions
// in the module that declare partial inits before the call to
super.init.
self.init(counts: numbers)
// Okay, now we super.init.
super.init()
// Fully initialized now.
}
}
extension A {
let counts: [Int]
partial init(counts: [Int]) {
// Definitive initialization requires a partial init to initialize all
the stored properties
// in this extension. This all happens prior to the complete
initialization of self,
// so unlike a normal init, there is no point in this initializer when
unrestricted
// use of self is allowed. If that’s required, it can be done with an
ordinary method
// call.
//
// To start, partial initializers would not be allowed to use properties
from other
// extensions or the main class. We can consider ways to lift that
restriction later.
self.counts = counts
}
}
John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
Sent from my iPad
> On Dec 24, 2015, at 1:31 PM, John McCall wrote:
>
>
>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson wrote:
>>
>>
On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
wrote:
On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote:
> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
> 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?
>
> Just spit-balling, but something like:
>
> class A {
>init(numbers: [Int]) {
> // Definitive initialization requires initialization of all the
> extensions
> // in the module that declare partial inits before the call to
> super.init.
> self.init(counts: numbers)
>
> // Okay, now we super.init.
> super.init()
>
> // Fully initialized now.
> }
> }
>
> extension A {
>let counts: [Int]
>partial init(counts: [Int]) {
> // Definitive initialization requires a partial init to initialize all
> the stored properties
> // in this extension. This all happens prior to the complete
> initialization of self,
> // so unlike a normal init, there is no point in this initializer when
> unrestricted
> // use of self is allowed. If that’s required, it can be done with an
> ordinary method
> // call.
> //
> // To start, partial initializers would not be allowed to use properties
> from other
> // extensions or the main class. We can consider ways to lift that
> restriction later.
>
> self.counts = counts
>}
> }
I'm really not sure I like this very much. It seems to be exactly what I was
concerned about. The primary advantage this seems to provide is encapsulation
for the extension. Unfortunately it also means the extension has a ripple
effect requiring initializers elsewhere in the project to be updated. This
doesn't feel like an "extension" as it actually seems to be pretty invasive.
It gives me an uneasy feeling at first glance.
I would like to see some concrete examples of problems this solves and
compelling reasons why it is better than the alternatives.
Matthew
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 24, 2015, at 11:48 AM, Matthew Johnson wrote:
>> On Dec 24, 2015, at 1:31 PM, John McCall wrote:
>>
>>
>>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson
>>> wrote:
>>>
>>>
> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
> wrote:
>
> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote:
>> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
>> 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?
>>
>> Just spit-balling, but something like:
>>
>> class A {
>> init(numbers: [Int]) {
>> // Definitive initialization requires initialization of all the
>> extensions
>> // in the module that declare partial inits before the call to
>> super.init.
>> self.init(counts: numbers)
>>
>> // Okay, now we super.init.
>> super.init()
>>
>> // Fully initialized now.
>>}
>> }
>>
>> extension A {
>> let counts: [Int]
>> partial init(counts: [Int]) {
>> // Definitive initialization requires a partial init to initialize all
>> the stored properties
>> // in this extension. This all happens prior to the complete
>> initialization of self,
>> // so unlike a normal init, there is no point in this initializer when
>> unrestricted
>> // use of self is allowed. If that’s required, it can be done with an
>> ordinary method
>> // call.
>> //
>> // To start, partial initializers would not be allowed to use properties
>> from other
>> // extensions or the main class. We can consider ways to lift that
>> restriction later.
>>
>> self.counts = counts
>> }
>> }
>
> I'm really not sure I like this very much. It seems to be exactly what I was
> concerned about. The primary advantage this seems to provide is
> encapsulation for the extension. Unfortunately it also means the extension
> has a ripple effect requiring initializers elsewhere in the project to be
> updated. This doesn't feel like an "extension" as it actually seems to be
> pretty invasive. It gives me an uneasy feeling at first glance.
Any proposal which allows stored properties with non-default initialization to
be added in an extension is going to require source changes to the main class
initializer(s). My suggestion of partial inits achieves that without breaking
encapsulation, which in my judgment would not be acceptable. You could also
just require all stored properties in extensions to have a default initializer,
which is the rule we’d be forced to use outside the module anyway. These are
your options if you actually care about this feature.
John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 24, 2015, at 2:05 PM, John McCall wrote:
>
>> On Dec 24, 2015, at 11:48 AM, Matthew Johnson wrote:
>>> On Dec 24, 2015, at 1:31 PM, John McCall wrote:
>>>
>>>
On Dec 23, 2015, at 10:51 AM, Matthew Johnson
wrote:
>> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
>> wrote:
>>
>> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote:
>>> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
>>> 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?
>>>
>>> Just spit-balling, but something like:
>>>
>>> class A {
>>> init(numbers: [Int]) {
>>> // Definitive initialization requires initialization of all the
>>> extensions
>>> // in the module that declare partial inits before the call to
>>> super.init.
>>> self.init(counts: numbers)
>>>
>>> // Okay, now we super.init.
>>> super.init()
>>>
>>> // Fully initialized now.
>>> }
>>> }
>>>
>>> extension A {
>>> let counts: [Int]
>>> partial init(counts: [Int]) {
>>>// Definitive initialization requires a partial init to initialize all
>>> the stored properties
>>>// in this extension. This all happens prior to the complete
>>> initialization of self,
>>>// so unlike a normal init, there is no point in this initializer when
>>> unrestricted
>>>// use of self is allowed. If that’s required, it can be done with an
>>> ordinary method
>>>// call.
>>>//
>>>// To start, partial initializers would not be allowed to use properties
>>> from other
>>>// extensions or the main class. We can consider ways to lift that
>>> restriction later.
>>>
>>>self.counts = counts
>>> }
>>> }
>>
>> I'm really not sure I like this very much. It seems to be exactly what I
>> was concerned about. The primary advantage this seems to provide is
>> encapsulation for the extension. Unfortunately it also means the extension
>> has a ripple effect requiring initializers elsewhere in the project to be
>> updated. This doesn't feel like an "extension" as it actually seems to be
>> pretty invasive. It gives me an uneasy feeling at first glance.
>
> Any proposal which allows stored properties with non-default initialization
> to be added in an extension is going to require source changes to the main
> class initializer(s). My suggestion of partial inits achieves that without
> breaking encapsulation, which in my judgment would not be acceptable. You
> could also just require all stored properties in extensions to have a default
> initializer, which is the rule we’d be forced to use outside the module
> anyway. These are your options if you actually care about this feature.
Understood. I’m still trying to asses how I feel about the idea in general.
There are certainly advantages, but there are also drawbacks, particularly when
the stored properties aren’t required to have defaults.
Matthew
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 24, 2015, at 12:10 PM, Matthew Johnson wrote:
>> On Dec 24, 2015, at 2:05 PM, John McCall wrote:
>>
>>> On Dec 24, 2015, at 11:48 AM, Matthew Johnson
>>> wrote:
On Dec 24, 2015, at 1:31 PM, John McCall wrote:
> On Dec 23, 2015, at 10:51 AM, Matthew Johnson
> wrote:
>
>
>>> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
>>> wrote:
>>>
>>> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote:
On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
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?
Just spit-balling, but something like:
class A {
init(numbers: [Int]) {
// Definitive initialization requires initialization of all the
extensions
// in the module that declare partial inits before the call to
super.init.
self.init(counts: numbers)
// Okay, now we super.init.
super.init()
// Fully initialized now.
}
}
extension A {
let counts: [Int]
partial init(counts: [Int]) {
// Definitive initialization requires a partial init to initialize all
the stored properties
// in this extension. This all happens prior to the complete
initialization of self,
// so unlike a normal init, there is no point in this initializer when
unrestricted
// use of self is allowed. If that’s required, it can be done with an
ordinary method
// call.
//
// To start, partial initializers would not be allowed to use properties
from other
// extensions or the main class. We can consider ways to lift that
restriction later.
self.counts = counts
}
}
>>>
>>> I'm really not sure I like this very much. It seems to be exactly what I
>>> was concerned about. The primary advantage this seems to provide is
>>> encapsulation for the extension. Unfortunately it also means the extension
>>> has a ripple effect requiring initializers elsewhere in the project to be
>>> updated. This doesn't feel like an "extension" as it actually seems to be
>>> pretty invasive. It gives me an uneasy feeling at first glance.
>>
>> Any proposal which allows stored properties with non-default initialization
>> to be added in an extension is going to require source changes to the main
>> class initializer(s). My suggestion of partial inits achieves that without
>> breaking encapsulation, which in my judgment would not be acceptable. You
>> could also just require all stored properties in extensions to have a
>> default initializer, which is the rule we’d be forced to use outside the
>> module anyway. These are your options if you actually care about this
>> feature.
>
> Understood. I’m still trying to asses how I feel about the idea in general.
> There are certainly advantages, but there are also drawbacks, particularly
> when the stored properties aren’t required to have defaults.
Here’s the key argument for me. What is the point of an extension of a
concrete type within the defining module? Extending a *protocol* has a lot of
expressive power, sure. Extending a *different* module’s type lets you avoid
awkward workarounds and makes code feel more consistent, sure. But extending
your own type, when you could have just written that code in the main
definition? It would surely reduce language complexity if we disallowed that.
And yet, people still want to do it, even though the only reason to do so is
code organization. Something about the code in the extension feels like a
logical grouping, which is verging on saying that it acts like a sub-system;
and a sub-system is something that should be encapsulated.
I don’t thi
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 25, 2015, at 12:02 AM, John McCall wrote:
>
>> On Dec 24, 2015, at 12:10 PM, Matthew Johnson wrote:
>>> On Dec 24, 2015, at 2:05 PM, John McCall wrote:
>>>
On Dec 24, 2015, at 11:48 AM, Matthew Johnson
wrote:
> On Dec 24, 2015, at 1:31 PM, John McCall wrote:
>
>
>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson
>> wrote:
>>
>>
On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
wrote:
On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote:
> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
> 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?
>
> Just spit-balling, but something like:
>
> class A {
> init(numbers: [Int]) {
> // Definitive initialization requires initialization of all the
> extensions
> // in the module that declare partial inits before the call to
> super.init.
> self.init(counts: numbers)
>
> // Okay, now we super.init.
> super.init()
>
> // Fully initialized now.
> }
> }
>
> extension A {
> let counts: [Int]
> partial init(counts: [Int]) {
> // Definitive initialization requires a partial init to initialize all
> the stored properties
> // in this extension. This all happens prior to the complete
> initialization of self,
> // so unlike a normal init, there is no point in this initializer when
> unrestricted
> // use of self is allowed. If that’s required, it can be done with an
> ordinary method
> // call.
> //
> // To start, partial initializers would not be allowed to use properties
> from other
> // extensions or the main class. We can consider ways to lift that
> restriction later.
>
> self.counts = counts
> }
> }
I'm really not sure I like this very much. It seems to be exactly what I
was concerned about. The primary advantage this seems to provide is
encapsulation for the extension. Unfortunately it also means the
extension has a ripple effect requiring initializers elsewhere in the
project to be updated. This doesn't feel like an "extension" as it
actually seems to be pretty invasive. It gives me an uneasy feeling at
first glance.
>>>
>>> Any proposal which allows stored properties with non-default initialization
>>> to be added in an extension is going to require source changes to the main
>>> class initializer(s). My suggestion of partial inits achieves that without
>>> breaking encapsulation, which in my judgment would not be acceptable. You
>>> could also just require all stored properties in extensions to have a
>>> default initializer, which is the rule we’d be forced to use outside the
>>> module anyway. These are your options if you actually care about this
>>> feature.
>>
>> Understood. I’m still trying to asses how I feel about the idea in general.
>> There are certainly advantages, but there are also drawbacks, particularly
>> when the stored properties aren’t required to have defaults.
>
> Here’s the key argument for me. What is the point of an extension of a
> concrete type within the defining module? Extending a *protocol* has a lot of
> expressive power, sure. Extending a *different* module’s type lets you avoid
> awkward workarounds and makes code feel more consistent, sure. But extending
> your own type, when you could have just written that code in the main
> definition? It would surely reduce language complexity if we disallowed
> that. And yet, people still want to do it, even though the only reason to do
> so is code organization. Something about the code in the extension fee
Re: [swift-evolution] Proposal - Allow properties in Extensions
I’ve been giving this further thought today.
Thinking about extensions that require non-default initialization led to
thinking about protocols that require non-default initialization.
I can see significant value in allowing protocols to have stored properties
that require non-default initialization. This would effectively get us all the
way to very robust, encapsulated mixin functionality. It would enable design
techniques that would not otherwise be possible.
Once we have a concept of “partial initialization” of self in the language
supporting it for same-module extensions starts to make more sense to me as a
natural way to build on that.
As with extensions requiring non-default initialization, conformance of such
protocols would only be supported in the module declaring the type itself, and
perhaps only in the declaration itself. This being the case, storage could even
be inline.
It might look something like this:
protocol P {
// requirements of the protocol
// ...
stored let s: String
protocol init(s: String) {
// protocol cannot use self to reference any of its instance requirements
yet
// as self is not fully initialized
self.s = s
}
}
class C: P {
let i: Int
init() {
i = 42
P.init(“hello”)
}
}
A few things to note.
The protocol would need a way to indicate its initializer is a partial
initializer that initializes the protocol’s storage rather than being an
initializer requirement. It would also need a way to indicate that specific
properties are stored directly rather than specifying requirements. I used
`stored` and `protocol init` for this purpose in the above example but the
syntax could look different in a final solution.
The protocol may also wish to apply access control to its stored members as
well.
If we allow both the protocol and the type itself to have distinct properties
with the same name they would need to have distinct storage. The protocol’s
stored property could not be treated as an overridable requirement of the
protocol. When accessing the type via its protocol interface the protocol’s
storage would be used. When accessing the type directly its storage would be
used.
I’m sure there are plenty more details to consider.
Given its potential to enable robust mixins, I am really starting to warm to
the idea of partial-self initialization.
Matthew
> On Dec 26, 2015, at 9:10 AM, Matthew Johnson via swift-evolution
> wrote:
>
>>
>> On Dec 25, 2015, at 12:02 AM, John McCall > > wrote:
>>
>>> On Dec 24, 2015, at 12:10 PM, Matthew Johnson >> > wrote:
On Dec 24, 2015, at 2:05 PM, John McCall >>> > wrote:
> On Dec 24, 2015, at 11:48 AM, Matthew Johnson > wrote:
>> On Dec 24, 2015, at 1:31 PM, John McCall > > wrote:
>>
>>
>>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson >> > wrote:
>>>
>>>
> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>
> On Dec 23, 2015, at 7:05 AM, Paul Cantrell > wrote:
>> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution
>> mailto: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?
>>
>> Just spit-balling, but something like:
>>
>> class A {
>> init(numbers: [Int]) {
>> // Definitive initialization requires initialization of all the
>> extensions
>> // in the module that declare partial inits before the call to
>> super.
Re: [swift-evolution] Proposal - Allow properties in Extensions
> On Dec 25, 2015, at 12:02 AM, John McCall 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. >>> …etc… > > I feel like the strongest argument against allowing stored properties in > extensions is the argument that it's poor design to have very complex types. > I have two responses to that; I apologize if this seems like straw-manning, > because I know you haven’t raised this objection. > > The first is that I’m always uncomfortable with abstract arguments against > the complexity of other people’s code. > … > The second is that this is a valuable tool for incrementally reducing that > complexity. There’s a third good argument as well: it decouples API design from scoping of private state. I find that readability at the point of API use often pulls against minimizing variable scope. A recent example: Siesta’s Resource class provides “latest best information” about the state of an HTTP resource, and lets you observe changes to that state. It’s nicest to work with the API when the same Resource class provides both of these things: activityIndicator.hidden = !resource.isLoading displayStuff(resource.latestData) resource.loadIfNeeded() resource.addObserver(self) However, in the implementation, I would like to expose the set of observers only to the observer-related methods, i.e. the private observers property should be exposed to addObserver() but hidden from loadIfNeeded()). Doing that using traditional methods gets ugly. I have to make a separate ResourceObservers type, and then … what? I can make it public, and force this API usage (which looks reasonable at first but rapidly gets awkward): resource.observers.add(self) …or I can make the ResourceObservers type private and follow Demeter’s so-called law to its ugly conclusion, and have a bunch of forwarding methods on Resource. Those API problems aside, I’m up a creek anyway: there’s _private_ state of Resource that both addObserver() and loadIfNeeded() need to see. Exposing that state to a separate ResourceObservers type is far messier than just letting the Resource class get a little bit bigger. Some form of “properties in extensions” could help ease this problem, letting extension scope group methods with just the state they need, while still letting us design API based on what looks best from the outside. This argument might even make the “extension properties” idea a little more compelling for structs. Cheers, Paul ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
