Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Paul Cantrell via swift-evolution]

This line of thought suggests that allowing stored properties for same-module 
extensions is not only much more feasible to implement, but also makes more 
sense at the user level.

> On Nov 10, 2016, at 4:36 AM, Jay Abbott  wrote:
> 
> Perhaps some types don’t lend themselves to being extended?
> 
> Intuitively I would think any extensions should not affect the core behaviour 
> at all. So if I extended a type by adding a property x, two instances with 
> everything else the same and different values of x should still be considered 
> equal by a type-specific equality check. For example you would agree that 1 + 
> 1 = 2 but what if the numbers were coloured red, blue, and yellow 
> respectively, like fridge-magnets, should 1(red) + 1(blue) = 2(yellow)? I 
> think yes. The colour is an extension, it doesn’t change the fundamental 
> concept or behaviour of an integer number.
> 
> I see extensions as a way to add functionality (and potentially data), but 
> without affecting the core behaviour. If you wanted to change behaviour then 
> you should use inheritance or composition to create something new. You can’t 
> then use your own type for instances created by a library, unless it gives 
> you a way to do that, the library would expect its own types to behave in a 
> predictable way, similarly they should behave the same way when extended.
> 
> 
> On Thu, 3 Nov 2016 at 15:14 Thorsten Seitz via swift-evolution 
> > wrote:
> Has anybody thought about the semantic issues of out-of-module extensions 
> with stored properties apart from the implementation issues?
> 
> Such properties could potentially wreak havoc with the semantics of the type 
> being extended. How would these properties play nice with an existing 
> definition of equality, for example? How can it be guaranteed that their 
> value is consistent with the remaining state? And kept that way in case of 
> mutability?
> 
> -Thorsten
> 
> > Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution 
> > >:
> >
> >
> >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution 
> >> > wrote:
> >>
> >> Let extensions introduce stored properties, but only in the same module as 
> >> the type’s definition. Then, the compiler can just take any extensions 
> >> into consideration when it’s determining the size of the type, just as if 
> >> the properties had been declared in the type. Declaring stored properties 
> >> on an extension outside of the type’s module results in a compiler error, 
> >> exactly as today. This would, without any performance drawbacks, solve one 
> >> of the big problems that people are hoping to solve via stored properties 
> >> in extensions—the ability to organize members by protocol conformance.
> >
> > Yes please! A big strong +1 to this from me. I can think of several 
> > specific chunks of problem code that this would clean up immensely.
> >
> > Contra Karl in another message, it’s _in-module_ stored property extensions 
> > that I want most frequently. By far.
> >
> > It seems to me that Charles’s idea could be introduced as its own proposal. 
> > If out-of-module stored property extensions do eventually become feasible, 
> > then Charles’s proposal is a good stepping stone. If they never do, then 
> > his proposal has done no harm.
> >
> > I realize this probably falls into the post-ABI stability bucket, but I’d 
> > love to help write/support the proposal when its time comes.
> >
> > Cheers,
> >
> > Paul
> >
> > ___
> > 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 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Perhaps some types don’t lend themselves to being extended?

Intuitively I would think any extensions should not affect the core
behaviour at all. So if I extended a type by adding a property x, two
instances with everything else the same and different values of x should
still be considered equal by a type-specific equality check. For example
you would agree that 1 + 1 = 2 but what if the numbers were coloured red,
blue, and yellow respectively, like fridge-magnets, should 1(red) + 1(blue)
= 2(yellow)? I think yes. The colour is an extension, it doesn’t change the
fundamental concept or behaviour of an integer number.

I see extensions as a way to add functionality (and potentially data), but
without affecting the core behaviour. If you wanted to change behaviour
then you should use inheritance or composition to create something new. You
can’t then use your own type for instances created by a library, unless it
gives you a way to do that, the library would expect its own types to
behave in a predictable way, similarly they should behave the same way when
extended.
​

On Thu, 3 Nov 2016 at 15:14 Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Has anybody thought about the semantic issues of out-of-module extensions
> with stored properties apart from the implementation issues?
>
> Such properties could potentially wreak havoc with the semantics of the
> type being extended. How would these properties play nice with an existing
> definition of equality, for example? How can it be guaranteed that their
> value is consistent with the remaining state? And kept that way in case of
> mutability?
>
> -Thorsten
>
> > Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution <
> swift-evolution@swift.org>:
> >
> >
> >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Let extensions introduce stored properties, but only in the same module
> as the type’s definition. Then, the compiler can just take any extensions
> into consideration when it’s determining the size of the type, just as if
> the properties had been declared in the type. Declaring stored properties
> on an extension outside of the type’s module results in a compiler error,
> exactly as today. This would, without any performance drawbacks, solve one
> of the big problems that people are hoping to solve via stored properties
> in extensions—the ability to organize members by protocol conformance.
> >
> > Yes please! A big strong +1 to this from me. I can think of several
> specific chunks of problem code that this would clean up immensely.
> >
> > Contra Karl in another message, it’s _in-module_ stored property
> extensions that I want most frequently. By far.
> >
> > It seems to me that Charles’s idea could be introduced as its own
> proposal. If out-of-module stored property extensions do eventually become
> feasible, then Charles’s proposal is a good stepping stone. If they never
> do, then his proposal has done no harm.
> >
> > I realize this probably falls into the post-ABI stability bucket, but
> I’d love to help write/support the proposal when its time comes.
> >
> > Cheers,
> >
> > Paul
> >
> > ___
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Thorsten Seitz via swift-evolution]

Has anybody thought about the semantic issues of out-of-module extensions with 
stored properties apart from the implementation issues?

Such properties could potentially wreak havoc with the semantics of the type 
being extended. How would these properties play nice with an existing 
definition of equality, for example? How can it be guaranteed that their value 
is consistent with the remaining state? And kept that way in case of mutability?

-Thorsten 

> Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution 
> :
> 
> 
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> Let extensions introduce stored properties, but only in the same module as 
>> the type’s definition. Then, the compiler can just take any extensions into 
>> consideration when it’s determining the size of the type, just as if the 
>> properties had been declared in the type. Declaring stored properties on an 
>> extension outside of the type’s module results in a compiler error, exactly 
>> as today. This would, without any performance drawbacks, solve one of the 
>> big problems that people are hoping to solve via stored properties in 
>> extensions—the ability to organize members by protocol conformance.
> 
> Yes please! A big strong +1 to this from me. I can think of several specific 
> chunks of problem code that this would clean up immensely.
> 
> Contra Karl in another message, it’s _in-module_ stored property extensions 
> that I want most frequently. By far.
> 
> It seems to me that Charles’s idea could be introduced as its own proposal. 
> If out-of-module stored property extensions do eventually become feasible, 
> then Charles’s proposal is a good stepping stone. If they never do, then his 
> proposal has done no harm.
> 
> I realize this probably falls into the post-ABI stability bucket, but I’d 
> love to help write/support the proposal when its time comes.
> 
> Cheers,
> 
> Paul
> 
> ___
> 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] stored properties in extensions (was: associated objects)

[Charles Srstka via swift-evolution]

> On Oct 16, 2016, at 6:56 PM, Benjamin Spratling via swift-evolution 
>  wrote:
> 
>> Benjamin:
>> 
>> Implementation wise, weak does *not* currently have the effect of storing 
>> associated values. It does however mean that any object with weak references 
>> stays allocated after being deinited, until all the weak references are 
>> evaluated and zeroed (they are not zeroed when the object deinits, zeroing 
>> is done lazily. See 
>> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
>>  
>> 
>>  for a detailed discussion).
>> 
>> However, this seems likely to change at some point when Greg's changes are 
>> merged. Weakly referenced objects would cause a side-table to be allocated, 
>> with the benefits that the object could be deallocated immediately after 
>> deinit, and only the side-table would hang around (to service attempts to 
>> access weak references, which would still be lazily zeroed). The small 
>> disadvantage of this (which only applies to instances that actually have had 
>> weak references) is that an extra pointer dereference is needed for retain, 
>> release, and weak reference access (and some other things). But a big 
>> advantage is that the side-allocation could be used for other things too, 
>> like stored properties.
> 
> Thanks for the reference to the article.  I always meant to take the time to 
> do that bit spelunking, never actually had the time, and the non-code 
> documentation I found claimed it was out of date so I didn't bother reading 
> it.  Of all the possible implementations I conjectured after hearing about 
> ARC when it was announced for Obj-C, this was not one of them.  And frankly, 
> reading it makes me want to quit working as a software developer and take up 
> writing psychological thrillers as my job.  :(

The implementation in Objective-C ARC was not the same as Swift's, IIRC. I 
believe that it zeroed the references out immediately at the time the object 
ran out of references, rather than doing it lazily the next time something 
tried to access the reference. I could be wrong, though.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Benjamin Spratling via swift-evolution]

>> Benjamin:
>> 
>> Implementation wise, weak does *not* currently have the effect of storing 
>> associated values. It does however mean that any object with weak references 
>> stays allocated after being deinited, until all the weak references are 
>> evaluated and zeroed (they are not zeroed when the object deinits, zeroing 
>> is done lazily. See 
>> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
>>  for a detailed discussion).
>> 
>> However, this seems likely to change at some point when Greg's changes are 
>> merged. Weakly referenced objects would cause a side-table to be allocated, 
>> with the benefits that the object could be deallocated immediately after 
>> deinit, and only the side-table would hang around (to service attempts to 
>> access weak references, which would still be lazily zeroed). The small 
>> disadvantage of this (which only applies to instances that actually have had 
>> weak references) is that an extra pointer dereference is needed for retain, 
>> release, and weak reference access (and some other things). But a big 
>> advantage is that the side-allocation could be used for other things too, 
>> like stored properties.

Thanks for the reference to the article.  I always meant to take the time to do 
that bit spelunking, never actually had the time, and the non-code 
documentation I found claimed it was out of date so I didn't bother reading it. 
 Of all the possible implementations I conjectured after hearing about ARC when 
it was announced for Obj-C, this was not one of them.  And frankly, reading it 
makes me want to quit working as a software developer and take up writing 
psychological thrillers as my job.  :(___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

T.J.: This would not replace the need for stored properties in extensions.
For example: Imagine adding a property to UIView in an extension, then
recursively traversing a view hierarchy and accessing the property. This
thought experiment should quickly show you why wrapping and adding
properties (or even subclassing and adding properties) simply won't work,
even if an easy forwarding mechanism were in place. You do not have control
of the creation of all those objects, so you can't make them your type, and
even if you could, you would have to provide a wrapper class for every
UIView subclass, and then what if another module also wants to do the same?

However, note that it would be possible to only add the extra storage to
instances where some additional properties are actually accessed/in-use.
The pointer for the stored property data in the side-table would simply be
nil if it has never been used.

On Sun, 16 Oct 2016 at 23:31 T.J. Usiyan  wrote:

> How much would convenient method forwarding when wrapping change how
> desirable this feature is? I am hesitant to add storage to already
> allocated instances if we can avoid it.
>
> On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Greg:
>
> I've CCed you in case you want to respond to my comments below about
> potentially optimising "extensionIvar" access without using a dictionary.
> See my response to Haravikk below.
>
> Benjamin:
>
> Implementation wise, weak does *not* currently have the effect of storing
> associated values. It does however mean that any object with weak
> references stays allocated after being deinited, until all the weak
> references are evaluated and zeroed (they are not zeroed when the object
> deinits, zeroing is done lazily. See
> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
> for a detailed discussion).
>
> However, this seems likely to change at some point when Greg's changes are
> merged. Weakly referenced objects would cause a side-table to be allocated,
> with the benefits that the object could be deallocated immediately after
> deinit, and only the side-table would hang around (to service attempts to
> access weak references, which would still be lazily zeroed). The small
> disadvantage of this (which only applies to instances that actually have
> had weak references) is that an extra pointer dereference is needed for
> retain, release, and weak reference access (and some other things). But a
> big advantage is that the side-allocation could be used for other things
> too, like stored properties.
>
> Haravikk:
>
> It can be done efficiently using Greg's proposed changes. The current
> implementation on his branch (
> https://github.com/gparker42/swift/tree/new-refcount-representation) does
> not have any extra space for stored properties, but he has discussed
> "extensionIvars" before on swift-dev, and proposed that the side-table
> structure contains a pointer to a dictionary for these. However, I think
> with some dynamic loader magic this could be implemented as a dynamic
> structure instead of a dictionary. Each time a module is loaded, the side
> allocation for stored properties could be extended and the offsets to the
> newly extended properties could be fixed-up based on the current size.
> Existing instances could be handled by using the structure size as a
> version number (stored at the beginning of this area), it would check if
> the instance is at the current version and migrate/update the structure as
> needed (realloc it and init the extended area to zero, updating the
> size/version field). These checks would be less overhead than a
> getter/setter function call, so using dot notation to access the properties
> would not be deceiving programmers about the cost.
>
> Anton:
>
> Why should it matter where data is stored? Can you expand on any reasons
> for wanting object data to be contiguous, or thinking that it shouldn't be
> allowed for Swift classes?
>
>
> ___
> 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] stored properties in extensions (was: associated objects)

[T.J. Usiyan via swift-evolution]

How much would convenient method forwarding when wrapping change how
desirable this feature is? I am hesitant to add storage to already
allocated instances if we can avoid it.

On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:

> Greg:
>
> I've CCed you in case you want to respond to my comments below about
> potentially optimising "extensionIvar" access without using a dictionary.
> See my response to Haravikk below.
>
> Benjamin:
>
> Implementation wise, weak does *not* currently have the effect of storing
> associated values. It does however mean that any object with weak
> references stays allocated after being deinited, until all the weak
> references are evaluated and zeroed (they are not zeroed when the object
> deinits, zeroing is done lazily. See https://www.mikeash.com/
> pyblog/friday-qa-2015-12-11-swift-weak-references.html for a detailed
> discussion).
>
> However, this seems likely to change at some point when Greg's changes are
> merged. Weakly referenced objects would cause a side-table to be allocated,
> with the benefits that the object could be deallocated immediately after
> deinit, and only the side-table would hang around (to service attempts to
> access weak references, which would still be lazily zeroed). The small
> disadvantage of this (which only applies to instances that actually have
> had weak references) is that an extra pointer dereference is needed for
> retain, release, and weak reference access (and some other things). But a
> big advantage is that the side-allocation could be used for other things
> too, like stored properties.
>
> Haravikk:
>
> It can be done efficiently using Greg's proposed changes. The current
> implementation on his branch (https://github.com/gparker42/
> swift/tree/new-refcount-representation) does not have any extra space for
> stored properties, but he has discussed "extensionIvars" before on
> swift-dev, and proposed that the side-table structure contains a pointer to
> a dictionary for these. However, I think with some dynamic loader magic
> this could be implemented as a dynamic structure instead of a dictionary.
> Each time a module is loaded, the side allocation for stored properties
> could be extended and the offsets to the newly extended properties could be
> fixed-up based on the current size. Existing instances could be handled by
> using the structure size as a version number (stored at the beginning of
> this area), it would check if the instance is at the current version and
> migrate/update the structure as needed (realloc it and init the extended
> area to zero, updating the size/version field). These checks would be less
> overhead than a getter/setter function call, so using dot notation to
> access the properties would not be deceiving programmers about the cost.
>
> Anton:
>
> Why should it matter where data is stored? Can you expand on any reasons
> for wanting object data to be contiguous, or thinking that it shouldn't be
> allowed for Swift classes?
>
>
> ___
> 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Greg:

I've CCed you in case you want to respond to my comments below about
potentially optimising "extensionIvar" access without using a dictionary.
See my response to Haravikk below.

Benjamin:

Implementation wise, weak does *not* currently have the effect of storing
associated values. It does however mean that any object with weak
references stays allocated after being deinited, until all the weak
references are evaluated and zeroed (they are not zeroed when the object
deinits, zeroing is done lazily. See
https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
for a detailed discussion).

However, this seems likely to change at some point when Greg's changes are
merged. Weakly referenced objects would cause a side-table to be allocated,
with the benefits that the object could be deallocated immediately after
deinit, and only the side-table would hang around (to service attempts to
access weak references, which would still be lazily zeroed). The small
disadvantage of this (which only applies to instances that actually have
had weak references) is that an extra pointer dereference is needed for
retain, release, and weak reference access (and some other things). But a
big advantage is that the side-allocation could be used for other things
too, like stored properties.

Haravikk:

It can be done efficiently using Greg's proposed changes. The current
implementation on his branch (
https://github.com/gparker42/swift/tree/new-refcount-representation) does
not have any extra space for stored properties, but he has discussed
"extensionIvars" before on swift-dev, and proposed that the side-table
structure contains a pointer to a dictionary for these. However, I think
with some dynamic loader magic this could be implemented as a dynamic
structure instead of a dictionary. Each time a module is loaded, the side
allocation for stored properties could be extended and the offsets to the
newly extended properties could be fixed-up based on the current size.
Existing instances could be handled by using the structure size as a
version number (stored at the beginning of this area), it would check if
the instance is at the current version and migrate/update the structure as
needed (realloc it and init the extended area to zero, updating the
size/version field). These checks would be less overhead than a
getter/setter function call, so using dot notation to access the properties
would not be deceiving programmers about the cost.

Anton:

Why should it matter where data is stored? Can you expand on any reasons
for wanting object data to be contiguous, or thinking that it shouldn't be
allowed for Swift classes?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Anton Zhilin via swift-evolution]

Currently, we can expect that fields of a type are all collected in the
same place. This expectation applies more for "static" and less for
"dynamic" types.
So I agree with the idea for @objc classes, strongly disagree for structs,
and disagree for regular classes.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Benjamin Spratling via swift-evolution]

I’m haven’t read the implementation, but as I see it, “weak” has the effect of 
storing associated values.  Can that mechanism be made generic?

> +1 from me too for internal extensions; I think this is the logical place to 
> start for now so we can see how many use cases this actually covers. 
> Personally I don't try to add functionality to types from other libraries, 
> and when I have to I try as much as possible to do it via wrapping; obviously 
> this doesn't cover the async type cases and others where it'd be hard to 
> re-wrap the values, but I think I'd like to know more about how common such 
> cases actually are.
> 
> However, allowing stored properties in local extensions is an absolute must 
> for a first step, and would be very useful as a first step.
> 
> 
> The problem I have with doing it for external types is that I just don't see 
> how it can be done efficiently; associated objects means looking up the 
> object to find what its associated values are, which isn't a negligible cost 
> if you're doing it frequently, and it makes me very uncomfortable to think of 
> hiding what is actually happening, as developers may think they're just using 
> a regular property without really appreciating the actual costs involved. At 
> the very least they need to handled through a .associated property or 
> whatever to make it much clearer that these aren't native properties in the 
> normal sense.
> ___
> 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] stored properties in extensions (was: associated objects)

[Haravikk via swift-evolution]

> On 15 Oct 2016, at 02:01, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> Let extensions introduce stored properties, but only in the same module as 
>> the type’s definition. Then, the compiler can just take any extensions into 
>> consideration when it’s determining the size of the type, just as if the 
>> properties had been declared in the type. Declaring stored properties on an 
>> extension outside of the type’s module results in a compiler error, exactly 
>> as today. This would, without any performance drawbacks, solve one of the 
>> big problems that people are hoping to solve via stored properties in 
>> extensions—the ability to organize members by protocol conformance.
> 
> Yes please! A big strong +1 to this from me. I can think of several specific 
> chunks of problem code that this would clean up immensely.

+1 from me too for internal extensions; I think this is the logical place to 
start for now so we can see how many use cases this actually covers. Personally 
I don't try to add functionality to types from other libraries, and when I have 
to I try as much as possible to do it via wrapping; obviously this doesn't 
cover the async type cases and others where it'd be hard to re-wrap the values, 
but I think I'd like to know more about how common such cases actually are.

However, allowing stored properties in local extensions is an absolute must for 
a first step, and would be very useful as a first step.


The problem I have with doing it for external types is that I just don't see 
how it can be done efficiently; associated objects means looking up the object 
to find what its associated values are, which isn't a negligible cost if you're 
doing it frequently, and it makes me very uncomfortable to think of hiding what 
is actually happening, as developers may think they're just using a regular 
property without really appreciating the actual costs involved. At the very 
least they need to handled through a .associated property or whatever to make 
it much clearer that these aren't native properties in the normal sense.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Constant via swift-evolution]

+1 for me for "in-module" as a stop-gap, since I imagine it would be the
quickest, and least disruptive, way to make this happen.

I would add the caveat that if we do so, I really hope we commit to making
stored properties available *everywhere* later.

Even though it's more often than not "in-module" where I need this, the
fewer "exceptions to the rule" we have in Swift the better. It gets tricky
trying to plan things out when one has to juggle too many features that
work in one context, but not another.

So +1 with the hope that it doesn't stay "in-module" till the end of time.



On Fri, Oct 14, 2016 at 6:01 PM, Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Let extensions introduce stored properties, but only in the same module
> as the type’s definition. Then, the compiler can just take any extensions
> into consideration when it’s determining the size of the type, just as if
> the properties had been declared in the type. Declaring stored properties
> on an extension outside of the type’s module results in a compiler error,
> exactly as today. This would, without any performance drawbacks, solve one
> of the big problems that people are hoping to solve via stored properties
> in extensions—the ability to organize members by protocol conformance.
>
> Yes please! A big strong +1 to this from me. I can think of several
> specific chunks of problem code that this would clean up immensely.
>
> Contra Karl in another message, it’s _in-module_ stored property
> extensions that I want most frequently. By far.
>
> It seems to me that Charles’s idea could be introduced as its own
> proposal. If out-of-module stored property extensions do eventually become
> feasible, then Charles’s proposal is a good stepping stone. If they never
> do, then his proposal has done no harm.
>
> I realize this probably falls into the post-ABI stability bucket, but I’d
> love to help write/support the proposal when its time comes.
>
> Cheers,
>
> Paul
>
> ___
> 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] stored properties in extensions (was: associated objects)

[Paul Cantrell via swift-evolution]

> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Let extensions introduce stored properties, but only in the same module as 
> the type’s definition. Then, the compiler can just take any extensions into 
> consideration when it’s determining the size of the type, just as if the 
> properties had been declared in the type. Declaring stored properties on an 
> extension outside of the type’s module results in a compiler error, exactly 
> as today. This would, without any performance drawbacks, solve one of the big 
> problems that people are hoping to solve via stored properties in 
> extensions—the ability to organize members by protocol conformance.

Yes please! A big strong +1 to this from me. I can think of several specific 
chunks of problem code that this would clean up immensely.

Contra Karl in another message, it’s _in-module_ stored property extensions 
that I want most frequently. By far.

It seems to me that Charles’s idea could be introduced as its own proposal. If 
out-of-module stored property extensions do eventually become feasible, then 
Charles’s proposal is a good stepping stone. If they never do, then his 
proposal has done no harm.

I realize this probably falls into the post-ABI stability bucket, but I’d love 
to help write/support the proposal when its time comes.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jonathan Hull via swift-evolution]

I was thinking for reference types we would probably want to use the extra 
space in the refcount field (as discussed earlier in the thread).  For value 
types, we might want to have a single data structure (probably COW) holding all 
associated values for the value types on the stack frame.  That way, we don’t 
have to double the size of an Int if someone adds an associated value in one or 
two cases.  We only add a pointer size to the entire stack frame in the case 
where no value types have associated values.

Thoughts?

Thanks,
Jon

> Karl, interesting point... perhaps a similar scheme could work for value
> types (using the COW refcount)?
> 
> On Thu, 13 Oct 2016 at 16:02 Karl Wagner  > wrote:
> 
> > That's great! I suppose the idea of allocating a bit of extra storage for
> > similar data in value types is some sort of heresy?
> >
> > Would there be a conceptual reason for that; which explains why it's okay
> > for reference-types but not for values? Personally I feel like it's a kind
> > of C legacy, due to performance and layout expectations that C sets about
> > value-types ¯\_(ツ)_/¯
> >
> > Karl
> >
> >
> > Sent from my iPad
> >
> > On 12 Oct 2016, at 07:54, Greg Parker  > > wrote:
> >
> >
> > On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution <
> > swift-evolution at swift.org 
> > > wrote:
> >
> > Implementation idea No. 4:
> >
> >
> > The basic concept is that the dynamic linker would fixup the offsets as
> > well as relocating the addersses, allowing the size of objects (and maybe
> > structs?) to change at link-time. The process might be something like this:
> >
> > * References to members defined in extensions would compile to have an
> > offset symbol instead of a value - so they can be fixed up later
> > * The linker would scan all the shared objects that are referenced (and
> > thus might get linked)
> > * Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for
> > each class.
> > * Append the extra fields (increase the size the class), decide where each
> > member goes in the extended layout and fixup the offsets
> > * Carry on with normal relocation
> >
> > There are quite a few assumptions in the above, and probably quite a few
> > misunderstandings about how things work on my part too (I'm not an expert
> > at this), however I think it should work in principle. Some questions about
> > my assumptions: Can linker know in advance all the potential modules that
> > could be linked, or is this done more lazily and it only knows about what
> > it's linking right now? Is it ok for the size to change - I don't know if
> > it's a static sizeof() or if it could be (or already is) stored in the isa?
> >
> >
> > This sort of scheme isn't dynamic enough. The worst-case is a extension in
> > a library that gets dlopen()ed at runtime on a class that is already
> > loaded. The build-time linker can't know anything about it. The loader and
> > the runtime will see it, but at that point the class may already be in use
> > and may already have instances allocated. If you want to handle the
> > dlopen() case then you need some way to add storage to arbitrary objects
> > that have already been allocated.
> >
> >
> > Ole Begemann wrote:
> >
> >
> > For what it's worth, Greg Parker (Cc'ed) started a discussion back in
> > March that I think is relevant here:
> > https://lists.swift.org/pipermail/swift-dev/Week- 
> > 
> > of-Mon-20160314/001424.html
> >
> > Here's the relevant part:
> >
> > "I am considering a new representation for Swift refcounts and other
> > per-object data. This is an outline of the scheme. Comments and suggestions
> > welcome.
> >
> > Today, each object stores 64-bits of refcounts and flags after the isa
> > field.
> >
> > In this new system, each object would store a pointer-size field after the
> > isa field. This field would have two cases: it could store refcounts and
> > flags, or it could store a pointer to a side allocation that would store
> > refcounts and flags and additional per-object data.
> >
> > Advantages:
> > …
> > * Allows inexpensive per-object storage for future features like
> > associated references or class extensions with instance variables.
> > …"
> >
> > I don't know the current status of this idea (implemented? planned?
> > abandoned?). Also, it's worth noting that this would only apply to classes,
> > not value types.
> >
> >
> > I'm working on this right now:
> > https://github.com/gparker42/swift/tree/new-refcount-representation 
> > 
> >
> > If it goes well it will provide the runtime implementation space needed
> > for associated objects or stored properties in extensions. Such storage
> > would be less efficient than "real" stored 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Karl, interesting point... perhaps a similar scheme could work for value
types (using the COW refcount)?

On Thu, 13 Oct 2016 at 16:02 Karl Wagner  wrote:

> That's great! I suppose the idea of allocating a bit of extra storage for
> similar data in value types is some sort of heresy?
>
> Would there be a conceptual reason for that; which explains why it's okay
> for reference-types but not for values? Personally I feel like it's a kind
> of C legacy, due to performance and layout expectations that C sets about
> value-types ¯\_(ツ)_/¯
>
> Karl
>
>
> Sent from my iPad
>
> On 12 Oct 2016, at 07:54, Greg Parker  wrote:
>
>
> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Implementation idea No. 4:
>
>
> The basic concept is that the dynamic linker would fixup the offsets as
> well as relocating the addersses, allowing the size of objects (and maybe
> structs?) to change at link-time. The process might be something like this:
>
> * References to members defined in extensions would compile to have an
> offset symbol instead of a value - so they can be fixed up later
> * The linker would scan all the shared objects that are referenced (and
> thus might get linked)
> * Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for
> each class.
> * Append the extra fields (increase the size the class), decide where each
> member goes in the extended layout and fixup the offsets
> * Carry on with normal relocation
>
> There are quite a few assumptions in the above, and probably quite a few
> misunderstandings about how things work on my part too (I'm not an expert
> at this), however I think it should work in principle. Some questions about
> my assumptions: Can linker know in advance all the potential modules that
> could be linked, or is this done more lazily and it only knows about what
> it's linking right now? Is it ok for the size to change - I don't know if
> it's a static sizeof() or if it could be (or already is) stored in the isa?
>
>
> This sort of scheme isn't dynamic enough. The worst-case is a extension in
> a library that gets dlopen()ed at runtime on a class that is already
> loaded. The build-time linker can't know anything about it. The loader and
> the runtime will see it, but at that point the class may already be in use
> and may already have instances allocated. If you want to handle the
> dlopen() case then you need some way to add storage to arbitrary objects
> that have already been allocated.
>
>
> Ole Begemann wrote:
>
>
> For what it's worth, Greg Parker (Cc'ed) started a discussion back in
> March that I think is relevant here:
> https://lists.swift.org/pipermail/swift-dev/Week-
> of-Mon-20160314/001424.html
>
> Here's the relevant part:
>
> "I am considering a new representation for Swift refcounts and other
> per-object data. This is an outline of the scheme. Comments and suggestions
> welcome.
>
> Today, each object stores 64-bits of refcounts and flags after the isa
> field.
>
> In this new system, each object would store a pointer-size field after the
> isa field. This field would have two cases: it could store refcounts and
> flags, or it could store a pointer to a side allocation that would store
> refcounts and flags and additional per-object data.
>
> Advantages:
> …
> * Allows inexpensive per-object storage for future features like
> associated references or class extensions with instance variables.
> …"
>
> I don't know the current status of this idea (implemented? planned?
> abandoned?). Also, it's worth noting that this would only apply to classes,
> not value types.
>
>
> I'm working on this right now:
> https://github.com/gparker42/swift/tree/new-refcount-representation
>
> If it goes well it will provide the runtime implementation space needed
> for associated objects or stored properties in extensions. Such storage
> would be less efficient than "real" stored properties. Any object with that
> storage attached would also suffer additional performance penalties to
> refcounting and deallocation. On the plus side there is no memory penalty
> to objects that don't have additional storage, and there is no contention
> over a big global association table like there is in Objective-C's
> associated object implementation.
>
> Note that the runtime implementation is not the only problem. The
> optimizer folks hate the fact that stored properties in extensions defeat
> the compiler's visibility into the deinit behavior of all types, even if
> most types are unaffected at runtime.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Karl Wagner via swift-evolution]

That's great! I suppose the idea of allocating a bit of extra storage for 
similar data in value types is some sort of heresy?

Would there be a conceptual reason for that; which explains why it's okay for 
reference-types but not for values? Personally I feel like it's a kind of C 
legacy, due to performance and layout expectations that C sets about 
value-types ¯\_(ツ)_/¯

Karl


Sent from my iPad

> On 12 Oct 2016, at 07:54, Greg Parker  wrote:
> 
> 
>> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution 
>>  wrote:
>> 
>> Implementation idea No. 4:
>> 
>> The basic concept is that the dynamic linker would fixup the offsets as well 
>> as relocating the addersses, allowing the size of objects (and maybe 
>> structs?) to change at link-time. The process might be something like this:
>> 
>> * References to members defined in extensions would compile to have an 
>> offset symbol instead of a value - so they can be fixed up later
>> * The linker would scan all the shared objects that are referenced (and thus 
>> might get linked)
>> * Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for 
>> each class.
>> * Append the extra fields (increase the size the class), decide where each 
>> member goes in the extended layout and fixup the offsets
>> * Carry on with normal relocation
>> 
>> There are quite a few assumptions in the above, and probably quite a few 
>> misunderstandings about how things work on my part too (I'm not an expert at 
>> this), however I think it should work in principle. Some questions about my 
>> assumptions: Can linker know in advance all the potential modules that could 
>> be linked, or is this done more lazily and it only knows about what it's 
>> linking right now? Is it ok for the size to change - I don't know if it's a 
>> static sizeof() or if it could be (or already is) stored in the isa?
> 
> This sort of scheme isn't dynamic enough. The worst-case is a extension in a 
> library that gets dlopen()ed at runtime on a class that is already loaded. 
> The build-time linker can't know anything about it. The loader and the 
> runtime will see it, but at that point the class may already be in use and 
> may already have instances allocated. If you want to handle the dlopen() case 
> then you need some way to add storage to arbitrary objects that have already 
> been allocated.
> 
> 
>> Ole Begemann wrote:
>> 
>> For what it's worth, Greg Parker (Cc'ed) started a discussion back in March 
>> that I think is relevant here: 
>> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html
>> 
>> Here's the relevant part:
>> 
>> "I am considering a new representation for Swift refcounts and other 
>> per-object data. This is an outline of the scheme. Comments and suggestions 
>> welcome.
>> 
>> Today, each object stores 64-bits of refcounts and flags after the isa field.
>> 
>> In this new system, each object would store a pointer-size field after the 
>> isa field. This field would have two cases: it could store refcounts and 
>> flags, or it could store a pointer to a side allocation that would store 
>> refcounts and flags and additional per-object data.
>> 
>> Advantages:
>> …
>> * Allows inexpensive per-object storage for future features like associated 
>> references or class extensions with instance variables.
>> …"
>> 
>> I don't know the current status of this idea (implemented? planned? 
>> abandoned?). Also, it's worth noting that this would only apply to classes, 
>> not value types.
> 
> I'm working on this right now: 
> https://github.com/gparker42/swift/tree/new-refcount-representation
> 
> If it goes well it will provide the runtime implementation space needed for 
> associated objects or stored properties in extensions. Such storage would be 
> less efficient than "real" stored properties. Any object with that storage 
> attached would also suffer additional performance penalties to refcounting 
> and deallocation. On the plus side there is no memory penalty to objects that 
> don't have additional storage, and there is no contention over a big global 
> association table like there is in Objective-C's associated object 
> implementation.
> 
> Note that the runtime implementation is not the only problem. The optimizer 
> folks hate the fact that stored properties in extensions defeat the 
> compiler's visibility into the deinit behavior of all types, even if most 
> types are unaffected at runtime.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I agree Karl, especially the bit about the difficulty of implementation
being the limiting thing here.

I think the language devs must have some idea how this will work, but don't
seem to want to share/discuss it at the moment. I was hoping for some
feedback about my implementation ideas - whether they are along the right
lines, or way off, or not necessary (because the implementation strategy is
already known). Perhaps this the wrong list for that kind of discussion?

Anyway, I was thinking some more and I had another idea about
implementation. This could be very useful for maintaining binary
compatability in other areas too.

Implementation idea No. 4:

The basic concept is that the dynamic linker would fixup the offsets as
well as relocating the addersses, allowing the size of objects (and maybe
structs?) to change at link-time. The process might be something like this:

* References to members defined in extensions would compile to have an
offset symbol instead of a value - so they can be fixed up later
* The linker would scan all the shared objects that are referenced (and
thus might get linked)
* Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for
each class.
* Append the extra fields (increase the size the class), decide where each
member goes in the extended layout and fixup the offsets
* Carry on with normal relocation

There are quite a few assumptions in the above, and probably quite a few
misunderstandings about how things work on my part too (I'm not an expert
at this), however I think it should work in principle. Some questions about
my assumptions: Can linker know in advance all the potential modules that
could be linked, or is this done more lazily and it only knows about what
it's linking right now? Is it ok for the size to change - I don't know if
it's a static sizeof() or if it could be (or already is) stored in the isa?

Would love to hear back from anyone who is familiar with the code if this
sounds viable or not. I'd love to go digging in there myself (I've tried a
few times but got lost) but I don't have time at the moment.


On Tue, 11 Oct 2016 at 08:19 Karl  wrote:

>
> > On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Right. The question is whether we *need* to add stored properties
> out-of-module, and what the use case for that is. To me it seems that
> adding them in-module is by far the more common use case, for the purposes
> of implementing protocols.
> >
> > At any rate, the rewrite option would be a great addition to Swift
> regardless of what our answer to the first question is.
> >
> > Charles
>
> I actually think out-of-module is the more common and important case. If
> you’re using a types from an external framework, it’s strange that you can
> retroactively add functionality but not additional data. That limitation,
> AFAICT, is purely due to implementation. Some well-constructed frameworks
> will allow you to add stored data to the types being used by subclassing.
> Not all are so well constructed, and as we have more and more value-types
> subclassing is not going to be a solution.
>
> You can add stored properties to objects in Python, which is one of the
> really great things about it. If you need to add a stored property to track
> some additional state you layer on top of a framework’s components, it’s
> staggering how easy it is - you don’t even need to define any new types.
>
> I personally think it’s important for Swift as a scripting language to
> have this ability - for value-types as well as classes, by default. We
> could optimise it away completely for types which aren’t public, and you
> should be able to explicitly declare a type non-extendable (similar to
> declaring it non-subclassable with ‘final’) to opt-out. I’m sure it will
> never happen, but there you go.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Karl via swift-evolution]

> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution 
>  wrote:
> 
> Right. The question is whether we *need* to add stored properties 
> out-of-module, and what the use case for that is. To me it seems that adding 
> them in-module is by far the more common use case, for the purposes of 
> implementing protocols.
> 
> At any rate, the rewrite option would be a great addition to Swift regardless 
> of what our answer to the first question is.
> 
> Charles

I actually think out-of-module is the more common and important case. If you’re 
using a types from an external framework, it’s strange that you can 
retroactively add functionality but not additional data. That limitation, 
AFAICT, is purely due to implementation. Some well-constructed frameworks will 
allow you to add stored data to the types being used by subclassing. Not all 
are so well constructed, and as we have more and more value-types subclassing 
is not going to be a solution.

You can add stored properties to objects in Python, which is one of the really 
great things about it. If you need to add a stored property to track some 
additional state you layer on top of a framework’s components, it’s staggering 
how easy it is - you don’t even need to define any new types.

I personally think it’s important for Swift as a scripting language to have 
this ability - for value-types as well as classes, by default. We could 
optimise it away completely for types which aren’t public, and you should be 
able to explicitly declare a type non-extendable (similar to declaring it 
non-subclassable with ‘final’) to opt-out. I’m sure it will never happen, but 
there you go.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charlie Monroe via swift-evolution]

Yes, there are valid use cases. 

For example, in case of many UI elements, you do not have control over their 
instantiation and need to associate a "help description" with them as an 
example. Which can be done by an additional property helpDescription added to 
NSView/UIView.

Another example that I've used is with CoreData, where you can store additional 
information on the MOC - NSManagedObjectContext is strongly discouraged from 
being subclassed. Example of the additional information is a synchronization 
manager assigned to the MOC.

And since in Swift, classes can be final, there may not be a way to subclass 
the class to add your properties instead.

IMHO, it is a valid request to be able to add additional stored properties via 
extensions.

> On Oct 10, 2016, at 9:15 PM, Charles Srstka  wrote:
> 
> Right. The question is whether we *need* to add stored properties 
> out-of-module, and what the use case for that is. To me it seems that adding 
> them in-module is by far the more common use case, for the purposes of 
> implementing protocols.
> 
> At any rate, the rewrite option would be a great addition to Swift regardless 
> of what our answer to the first question is.
> 
> Charles
> 
>> On Oct 9, 2016, at 4:32 PM, Jay Abbott > > wrote:
>> 
>> Charles,
>> 
>> That would be good. It is a nicer way to write what is already possible to 
>> achieve, but it's not a way to 'implement' stored properties in extensions.
>> 
>> On Sun, 9 Oct 2016 at 21:45 Charles Srstka > > wrote:
>> *Replace both instances of “class C: P” with just “class C” since the 
>> conformance comes in the extension. That’s what I get for writing this 
>> quickly.
>> 
>> Charles
>> 
>>> On Oct 9, 2016, at 3:43 PM, Charles Srstka >> > wrote:
>>> 
>>> protocol P {
>>> var foo: String { get }
>>> func bar()
>>> }
>>> 
>>> protocol Q {
>>> var baz: Int { get }
>>> func qux()
>>> }
>>> 
>>> class C: P {
>>> var foo: String // <- what is this doing here?
>>> var baz: Int // <- ditto
>>> }
>>> 
>>> extension C: P {
>>> func bar() {}
>>> }
>>> 
>>> extension C: Q {
>>> func qux() {}
>>> }
>>> 
>>> we could simply:
>>> 
>>> protocol P {
>>> var foo: String { get }
>>> func bar()
>>> }
>>> 
>>> class C: P {}
>>> 
>>> extension C: P {
>>> var foo: String
>>> func bar() {}
>>> }
>>> 
>>> extension C: Q {
>>> var baz: Int
>>> func qux() {}
>>> }
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Srstka via swift-evolution]

Right. The question is whether we *need* to add stored properties 
out-of-module, and what the use case for that is. To me it seems that adding 
them in-module is by far the more common use case, for the purposes of 
implementing protocols.

At any rate, the rewrite option would be a great addition to Swift regardless 
of what our answer to the first question is.

Charles

> On Oct 9, 2016, at 4:32 PM, Jay Abbott  wrote:
> 
> Charles,
> 
> That would be good. It is a nicer way to write what is already possible to 
> achieve, but it's not a way to 'implement' stored properties in extensions.
> 
> On Sun, 9 Oct 2016 at 21:45 Charles Srstka  > wrote:
> *Replace both instances of “class C: P” with just “class C” since the 
> conformance comes in the extension. That’s what I get for writing this 
> quickly.
> 
> Charles
> 
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka > > wrote:
>> 
>> protocol P {
>>  var foo: String { get }
>>  func bar()
>> }
>> 
>> protocol Q {
>>  var baz: Int { get }
>>  func qux()
>> }
>> 
>> class C: P {
>>  var foo: String // <- what is this doing here?
>>  var baz: Int // <- ditto
>> }
>> 
>> extension C: P {
>>  func bar() {}
>> }
>> 
>> extension C: Q {
>>  func qux() {}
>> }
>> 
>> we could simply:
>> 
>> protocol P {
>>  var foo: String { get }
>>  func bar()
>> }
>> 
>> class C: P {}
>> 
>> extension C: P {
>>  var foo: String
>>  func bar() {}
>> }
>> 
>> extension C: Q {
>>  var baz: Int
>>  func qux() {}
>> }
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charlie Monroe via swift-evolution]

> On Oct 10, 2016, at 1:13 PM, Jay Abbott  wrote:
> 
> I understand Charlie. A few points though:
> a) I'm talking about pure Swift, this is absolutely nothing to do with 
> Objective-C;

Sure, but in either case you will need to somehow solve locking of the 
structure holding the additional values.

> b) If you read back on the AO thread you'll see that initially I was thinking 
> "I want AO because it will give me stored properties in extensions" when 
> really I should have been thinking "I want stored properties in extensions". 
> So this discussion is no longer about AO at all, hence the new subject.

Agreed, though the actual backing of the values won't be a lot different from 
the AO - it can be called differently, but the fact that it is likely to be 
stored in a dictionary brings resemblence to AO - and what I've mentioned are a 
few downsides to how AO are implemented at this point.

> c) Protocol conformance in an extension cannot tell the compiler to add 
> members to classes defined in other precompiled modules, as it is not 
> compiling them. When you do have the code and you are compiling it yourself, 
> you actually don't *need* stored properties in extensions because you can 
> work around it (although it would be nice), so the case where you actually 
> need it is where you want to extend someone else's precompiled class.

This is why I mentioned that this "magic protocol" would be off limits to 
extensions. Perhaps the choice of a protocol to this was incorrect - better way 
would be to use an annotation like @allows_extension_properties or similar.

I bet you that in any case, there will be a lot of people on this list that 
will want explicit opt-in, or at least a way to opt-out.

> 
> On Mon, 10 Oct 2016 at 06:04 Charlie Monroe  > wrote:
> No, I've also suggested how it would be implemented. It would, as I've 
> described, require support from the compiler and runtime - the protocol 
> conformance would tell the compiler to include an extra space in the instance 
> layout for [AnyHashable : Any], which would get to be used by the runtime to 
> store AO.
> 
> Note that the implementation noted below does not use any locks at all - 
> unlike ObjC AO, it's not thread-safe.
> 
> With AO, the main bottleneck always was that everything was stored in one 
> place - this way, each object would have its own AOs stored within itself. 
> This way, instead of a single spin (!) lock 
> (https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-references.mm
>  
> ),
>  you can use a lock pool - e.g. you have a dozen locks, depending on the hash 
> of the object itself, you decide which lock to use - this lowers the 
> contention a lot.
> 
> Try to run a few threads, read, write AO using the ObjC runtime - you'll see 
> how painfully slow it is - this is not something that should be in Swift.
> 
> 
>> On Oct 9, 2016, at 10:15 PM, Jay Abbott > > wrote:
>> 
>> Charlie,
>> 
>> What you suggest defines how you would use it from your code, not how it 
>> would be implemented in the language. If you look at my AO implementation it 
>> does what you say:
>> https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
>>  
>> 
>> i.e. has a protocol called 'Associable' and you opt classes into it to get 
>> the behaviour. This works and is usable, but the implementation leaves a lot 
>> to be desired (it's not optimal and while the interface is clean the 
>> implementation is not). Anyway - I was trying to steer the conversation AWAY 
>> from AOs towards stored properties in extensions, since Robert Widmann 
>> helped me to understand that AO was just a *means*, whereas stored 
>> properties in extensions is the *end*.
>> 
>> In fact we don't need a solution to the problem of "how to define/use stored 
>> properties in extensions" because the existing syntax for extensions is 
>> perfectly fine. Currently you get an error if you try to define a stored 
>> property in an extension, so no new syntax is needed, we just remove that 
>> error and make it work.
>> 
>> Of course a runtime-check may be needed if there is doubt about whether a 
>> dynamically linked module supported this feature - so this might invalidate 
>> what I just said above, or it might still be possible if the runtime does 
>> the check automatically when an extension is linked and puts a different 
>> implementation in place for older modules.
>> 
>> I'm just airing some thoughts at the moment to see what people think and try 
>> to get some technical feedback on viability. So it's not all fully thought 
>> through :D
>> 
>> 
>> On Sun, 9 Oct 2016 at 20:54 Charlie Monroe 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I understand Charlie. A few points though:
a) I'm talking about pure Swift, this is absolutely nothing to do with
Objective-C;
b) If you read back on the AO thread you'll see that initially I was
thinking "I want AO because it will give me stored properties in
extensions" when really I should have been thinking "I want stored
properties in extensions". So this discussion is no longer about AO at all,
hence the new subject.
c) Protocol conformance in an extension cannot tell the compiler to add
members to classes defined in other precompiled modules, as it is not
compiling them. When you do have the code and you are compiling it
yourself, you actually don't *need* stored properties in extensions because
you can work around it (although it would be nice), so the case where you
actually need it is where you want to extend someone else's precompiled
class.

On Mon, 10 Oct 2016 at 06:04 Charlie Monroe 
wrote:

> No, I've also suggested how it would be implemented. It would, as I've
> described, require support from the compiler and runtime - the protocol
> conformance would tell the compiler to include an extra space in the
> instance layout for [AnyHashable : Any], which would get to be used by the
> runtime to store AO.
>
> Note that the implementation noted below does not use any locks at all -
> unlike ObjC AO, it's not thread-safe.
>
> With AO, the main bottleneck always was that everything was stored in one
> place - this way, each object would have its own AOs stored within itself.
> This way, instead of a single spin (!) lock (
> https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-references.mm),
> you can use a lock pool - e.g. you have a dozen locks, depending on the
> hash of the object itself, you decide which lock to use - this lowers the
> contention a lot.
>
> Try to run a few threads, read, write AO using the ObjC runtime - you'll
> see how painfully slow it is - this is not something that should be in
> Swift.
>
>
> On Oct 9, 2016, at 10:15 PM, Jay Abbott  wrote:
>
> Charlie,
>
> What you suggest defines how you would use it from your code, not how it
> would be implemented in the language. If you look at my AO implementation
> it does what you say:
>
> https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
> i.e. has a protocol called 'Associable' and you opt classes into it to get
> the behaviour. This works and is usable, but the implementation leaves a
> lot to be desired (it's not optimal and while the interface is clean the
> implementation is not). Anyway - I was trying to steer the conversation
> AWAY from AOs towards stored properties in extensions, since Robert Widmann
> helped me to understand that AO was just a *means*, whereas stored
> properties in extensions is the *end*.
>
> In fact we don't need a solution to the problem of "how to define/use
> stored properties in extensions" because the existing syntax for extensions
> is perfectly fine. Currently you get an error if you try to define a stored
> property in an extension, so no new syntax is needed, we just remove that
> error and make it work.
>
> Of course a runtime-check may be needed if there is doubt about whether a
> dynamically linked module supported this feature - so this might invalidate
> what I just said above, or it might still be possible if the runtime does
> the check automatically when an extension is linked and puts a different
> implementation in place for older modules.
>
> I'm just airing some thoughts at the moment to see what people think and
> try to get some technical feedback on viability. So it's not all fully
> thought through :D
>
>
> On Sun, 9 Oct 2016 at 20:54 Charlie Monroe 
> wrote:
>
> There is a 4th way.
>
> Introduce an internal protocol Associatable, which would tell the compiler
> to add an additional (hidden) field to the object which would include the
> "dictionary" of key -> value associated values. (It would be off-limits to
> extensions, of course).
>
> This way:
>
> - it won't be a single dictionary containing all the associated values
> - classes can opt-in to this
> - the dictionary will be per-instance
>
> This is a midway between the current implementation of ObjC associated
> objects and of what someone has suggested to have an extra space for each
> object for the AO...
>
>
> On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have been thinking further on this and in addition to my previous two
> thoughts about implementation, I have had another idea...
>
> 3. If there is a bit spare in the object header somewhere (that is
> currently always zero), this could be used to signify the presence of an
> additional struct that immediately follows after the existing object data.
> I *think* that this method would allow binary compatibility with older
> modules. Instances that have this bit set would allow 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charlie Monroe via swift-evolution]

No, I've also suggested how it would be implemented. It would, as I've 
described, require support from the compiler and runtime - the protocol 
conformance would tell the compiler to include an extra space in the instance 
layout for [AnyHashable : Any], which would get to be used by the runtime to 
store AO.

Note that the implementation noted below does not use any locks at all - unlike 
ObjC AO, it's not thread-safe.

With AO, the main bottleneck always was that everything was stored in one place 
- this way, each object would have its own AOs stored within itself. This way, 
instead of a single spin (!) lock 
(https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-references.mm 
),
 you can use a lock pool - e.g. you have a dozen locks, depending on the hash 
of the object itself, you decide which lock to use - this lowers the contention 
a lot.

Try to run a few threads, read, write AO using the ObjC runtime - you'll see 
how painfully slow it is - this is not something that should be in Swift.


> On Oct 9, 2016, at 10:15 PM, Jay Abbott  wrote:
> 
> Charlie,
> 
> What you suggest defines how you would use it from your code, not how it 
> would be implemented in the language. If you look at my AO implementation it 
> does what you say:
> https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
>  
> 
> i.e. has a protocol called 'Associable' and you opt classes into it to get 
> the behaviour. This works and is usable, but the implementation leaves a lot 
> to be desired (it's not optimal and while the interface is clean the 
> implementation is not). Anyway - I was trying to steer the conversation AWAY 
> from AOs towards stored properties in extensions, since Robert Widmann helped 
> me to understand that AO was just a *means*, whereas stored properties in 
> extensions is the *end*.
> 
> In fact we don't need a solution to the problem of "how to define/use stored 
> properties in extensions" because the existing syntax for extensions is 
> perfectly fine. Currently you get an error if you try to define a stored 
> property in an extension, so no new syntax is needed, we just remove that 
> error and make it work.
> 
> Of course a runtime-check may be needed if there is doubt about whether a 
> dynamically linked module supported this feature - so this might invalidate 
> what I just said above, or it might still be possible if the runtime does the 
> check automatically when an extension is linked and puts a different 
> implementation in place for older modules.
> 
> I'm just airing some thoughts at the moment to see what people think and try 
> to get some technical feedback on viability. So it's not all fully thought 
> through :D
> 
> 
> On Sun, 9 Oct 2016 at 20:54 Charlie Monroe  > wrote:
> There is a 4th way.
> 
> Introduce an internal protocol Associatable, which would tell the compiler to 
> add an additional (hidden) field to the object which would include the 
> "dictionary" of key -> value associated values. (It would be off-limits to 
> extensions, of course).
> 
> This way:
> 
> - it won't be a single dictionary containing all the associated values
> - classes can opt-in to this
> - the dictionary will be per-instance
> 
> This is a midway between the current implementation of ObjC associated 
> objects and of what someone has suggested to have an extra space for each 
> object for the AO...
> 
> 
>> On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution 
>> > wrote:
>> 
>> I have been thinking further on this and in addition to my previous two 
>> thoughts about implementation, I have had another idea...
>> 
>> 3. If there is a bit spare in the object header somewhere (that is currently 
>> always zero), this could be used to signify the presence of an additional 
>> struct that immediately follows after the existing object data. I *think* 
>> that this method would allow binary compatibility with older modules. 
>> Instances that have this bit set would allow stored properties in 
>> extensions. The struct at the end would have one member, a pointer to a 
>> table of additional objects/values, stored properties defined in extensions 
>> could be stored in here, using a hash derived from the 
>> module/protocol/extension/property name (or something better if it exists).
>> 
>> The struct could be very simple as described above or more complex, with 
>> additional features, for example a list of deinit hooks, dynamically added 
>> methods, etc. The struct itself may also be dynamic in size/layout if such 
>> complexity is warranted by size or extensibility concerns. Perhaps it should 
>> start with some flags and 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Charles,

That would be good. It is a nicer way to write what is already possible to
achieve, but it's not a way to 'implement' stored properties in extensions.

On Sun, 9 Oct 2016 at 21:45 Charles Srstka  wrote:

> *Replace both instances of “class C: P” with just “class C” since the
> conformance comes in the extension. That’s what I get for writing this
> quickly.
>
> Charles
>
> On Oct 9, 2016, at 3:43 PM, Charles Srstka 
> wrote:
>
> protocol P {
> var foo: String { get }
> func bar()
> }
>
> protocol Q {
> var baz: Int { get }
> func qux()
> }
>
> class C: P {
> var foo: String // <- what is this doing here?
> var baz: Int // <- ditto
> }
>
> extension C: P {
> func bar() {}
> }
>
> extension C: Q {
> func qux() {}
> }
>
> we could simply:
>
> protocol P {
> var foo: String { get }
> func bar()
> }
>
> class C: P {}
>
> extension C: P {
> var foo: String
> func bar() {}
> }
>
> extension C: Q {
> var baz: Int
> func qux() {}
> }
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Srstka via swift-evolution]

*Replace both instances of “class C: P” with just “class C” since the 
conformance comes in the extension. That’s what I get for writing this quickly.

Charles

> On Oct 9, 2016, at 3:43 PM, Charles Srstka  wrote:
> 
> protocol P {
>   var foo: String { get }
>   func bar()
> }
> 
> protocol Q {
>   var baz: Int { get }
>   func qux()
> }
> 
> class C: P {
>   var foo: String // <- what is this doing here?
>   var baz: Int // <- ditto
> }
> 
> extension C: P {
>   func bar() {}
> }
> 
> extension C: Q {
>   func qux() {}
> }
> 
> we could simply:
> 
> protocol P {
>   var foo: String { get }
>   func bar()
> }
> 
> class C: P {}
> 
> extension C: P {
>   var foo: String
>   func bar() {}
> }
> 
> extension C: Q {
>   var baz: Int
>   func qux() {}
> }

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Srstka via swift-evolution]

How about a 5th way?

5. Let extensions introduce stored properties, but only in the same module as 
the type’s definition. Then, the compiler can just take any extensions into 
consideration when it’s determining the size of the type, just as if the 
properties had been declared in the type. Declaring stored properties on an 
extension outside of the type’s module results in a compiler error, exactly as 
today. This would, without any performance drawbacks, solve one of the big 
problems that people are hoping to solve via stored properties in 
extensions—the ability to organize members by protocol conformance. So, instead 
of this:

protocol P {
var foo: String { get }
func bar()
}

protocol Q {
var baz: Int { get }
func qux()
}

class C: P {
var foo: String // <- what is this doing here?
var baz: Int // <- ditto
}

extension C: P {
func bar() {}
}

extension C: Q {
func qux() {}
}

we could simply:

protocol P {
var foo: String { get }
func bar()
}

class C: P {}

extension C: P {
var foo: String
func bar() {}
}

extension C: Q {
var baz: Int
func qux() {}
}

So much cleaner, and since the compiler will simply turn the latter into the 
former at compile time, works without sacrificing anything in terms of 
performance.

Also, if we really decide that we need to have stored properties on *all* 
extensions, this idea still leaves the door open for using one of the methods 
discussed in this thread, in the case where the extension is in a different 
module from the original type.

Charles

> On Oct 9, 2016, at 2:53 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> There is a 4th way.
> 
> Introduce an internal protocol Associatable, which would tell the compiler to 
> add an additional (hidden) field to the object which would include the 
> "dictionary" of key -> value associated values. (It would be off-limits to 
> extensions, of course).
> 
> This way:
> 
> - it won't be a single dictionary containing all the associated values
> - classes can opt-in to this
> - the dictionary will be per-instance
> 
> This is a midway between the current implementation of ObjC associated 
> objects and of what someone has suggested to have an extra space for each 
> object for the AO...
> 
> 
>> On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution 
>> > wrote:
>> 
>> I have been thinking further on this and in addition to my previous two 
>> thoughts about implementation, I have had another idea...
>> 
>> 3. If there is a bit spare in the object header somewhere (that is currently 
>> always zero), this could be used to signify the presence of an additional 
>> struct that immediately follows after the existing object data. I *think* 
>> that this method would allow binary compatibility with older modules. 
>> Instances that have this bit set would allow stored properties in 
>> extensions. The struct at the end would have one member, a pointer to a 
>> table of additional objects/values, stored properties defined in extensions 
>> could be stored in here, using a hash derived from the 
>> module/protocol/extension/property name (or something better if it exists).
>> 
>> The struct could be very simple as described above or more complex, with 
>> additional features, for example a list of deinit hooks, dynamically added 
>> methods, etc. The struct itself may also be dynamic in size/layout if such 
>> complexity is warranted by size or extensibility concerns. Perhaps it should 
>> start with some flags and its size (size would be fixed and only increase 
>> with revisions so this would double as a 'version' number).
>> 
>> If viable - this would be a much better way to implement this feature than 
>> my previous two ideas. It doesn't require global lookups or additional 
>> levels of indirection beyond accessing the dynamic data/feature itself.
>> 
>> 
>> On Mon, 3 Oct 2016 at 04:13 Jay Abbott > > wrote:
>> Are stored properties in extensions already being discussed elsewhere? Is 
>> this one of those deferred-but-not-indexed-anywhere subjects?
>> 
>> I wonder how stored properties could potentially be implemented, I can only 
>> think of two ways:
>> 
>> 1. An extra pointer per instance (with resulting ABI compatability 
>> implications) to hold a collection of the stored items.
>> 
>> 2. A global lookup for any instance where stored properties have been set.
>> 
>> I'm not a language implementation expert, or familiar with the swift 
>> implementation, so there may be other/better ways - I'd like to know if 
>> there are?
>> 
>> If not, and option 2 was employed, a little foresight might enable the 
>> mechanism to be overloaded in the future for other dynamic features too. A 
>> bit flag (I'm hoping there's a spare bit in an existing flags field 
>> somewhere?) 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Charlie,

What you suggest defines how you would use it from your code, not how it
would be implemented in the language. If you look at my AO implementation
it does what you say:
https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
i.e. has a protocol called 'Associable' and you opt classes into it to get
the behaviour. This works and is usable, but the implementation leaves a
lot to be desired (it's not optimal and while the interface is clean the
implementation is not). Anyway - I was trying to steer the conversation
AWAY from AOs towards stored properties in extensions, since Robert Widmann
helped me to understand that AO was just a *means*, whereas stored
properties in extensions is the *end*.

In fact we don't need a solution to the problem of "how to define/use
stored properties in extensions" because the existing syntax for extensions
is perfectly fine. Currently you get an error if you try to define a stored
property in an extension, so no new syntax is needed, we just remove that
error and make it work.

Of course a runtime-check may be needed if there is doubt about whether a
dynamically linked module supported this feature - so this might invalidate
what I just said above, or it might still be possible if the runtime does
the check automatically when an extension is linked and puts a different
implementation in place for older modules.

I'm just airing some thoughts at the moment to see what people think and
try to get some technical feedback on viability. So it's not all fully
thought through :D


On Sun, 9 Oct 2016 at 20:54 Charlie Monroe 
wrote:

There is a 4th way.

Introduce an internal protocol Associatable, which would tell the compiler
to add an additional (hidden) field to the object which would include the
"dictionary" of key -> value associated values. (It would be off-limits to
extensions, of course).

This way:

- it won't be a single dictionary containing all the associated values
- classes can opt-in to this
- the dictionary will be per-instance

This is a midway between the current implementation of ObjC associated
objects and of what someone has suggested to have an extra space for each
object for the AO...


On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:

I have been thinking further on this and in addition to my previous two
thoughts about implementation, I have had another idea...

3. If there is a bit spare in the object header somewhere (that is
currently always zero), this could be used to signify the presence of an
additional struct that immediately follows after the existing object data.
I *think* that this method would allow binary compatibility with older
modules. Instances that have this bit set would allow stored properties in
extensions. The struct at the end would have one member, a pointer to a
table of additional objects/values, stored properties defined in extensions
could be stored in here, using a hash derived from the
module/protocol/extension/property name (or something better if it exists).

The struct could be very simple as described above or more complex, with
additional features, for example a list of deinit hooks, dynamically added
methods, etc. The struct itself may also be dynamic in size/layout if such
complexity is warranted by size or extensibility concerns. Perhaps it
should start with some flags and its size (size would be fixed and only
increase with revisions so this would double as a 'version' number).

If viable - this would be a much better way to implement this feature than
my previous two ideas. It doesn't require global lookups or additional
levels of indirection beyond accessing the dynamic data/feature itself.


On Mon, 3 Oct 2016 at 04:13 Jay Abbott  wrote:

Are stored properties in extensions already being discussed elsewhere? Is
this one of those deferred-but-not-indexed-anywhere subjects?

I wonder how stored properties could potentially be implemented, I can only
think of two ways:

1. An extra pointer per instance (with resulting ABI compatability
implications) to hold a collection of the stored items.

2. A global lookup for any instance where stored properties have been set.

I'm not a language implementation expert, or familiar with the swift
implementation, so there may be other/better ways - I'd like to know if
there are?

If not, and option 2 was employed, a little foresight might enable the
mechanism to be overloaded in the future for other dynamic features too. A
bit flag (I'm hoping there's a spare bit in an existing flags field
somewhere?) could indicate whether any feature had caused the object to be
added to this lookup and deinit could check this bit and make sure the
object is removed, thus any stored properties are nilled. The lookup value
could be a struct with one member (extensionStoredProperties), and
additional members can be added in future for new features.

I get the 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charlie Monroe via swift-evolution]

There is a 4th way.

Introduce an internal protocol Associatable, which would tell the compiler to 
add an additional (hidden) field to the object which would include the 
"dictionary" of key -> value associated values. (It would be off-limits to 
extensions, of course).

This way:

- it won't be a single dictionary containing all the associated values
- classes can opt-in to this
- the dictionary will be per-instance

This is a midway between the current implementation of ObjC associated objects 
and of what someone has suggested to have an extra space for each object for 
the AO...


> On Oct 9, 2016, at 9:47 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> I have been thinking further on this and in addition to my previous two 
> thoughts about implementation, I have had another idea...
> 
> 3. If there is a bit spare in the object header somewhere (that is currently 
> always zero), this could be used to signify the presence of an additional 
> struct that immediately follows after the existing object data. I *think* 
> that this method would allow binary compatibility with older modules. 
> Instances that have this bit set would allow stored properties in extensions. 
> The struct at the end would have one member, a pointer to a table of 
> additional objects/values, stored properties defined in extensions could be 
> stored in here, using a hash derived from the 
> module/protocol/extension/property name (or something better if it exists).
> 
> The struct could be very simple as described above or more complex, with 
> additional features, for example a list of deinit hooks, dynamically added 
> methods, etc. The struct itself may also be dynamic in size/layout if such 
> complexity is warranted by size or extensibility concerns. Perhaps it should 
> start with some flags and its size (size would be fixed and only increase 
> with revisions so this would double as a 'version' number).
> 
> If viable - this would be a much better way to implement this feature than my 
> previous two ideas. It doesn't require global lookups or additional levels of 
> indirection beyond accessing the dynamic data/feature itself.
> 
> 
> On Mon, 3 Oct 2016 at 04:13 Jay Abbott  > wrote:
> Are stored properties in extensions already being discussed elsewhere? Is 
> this one of those deferred-but-not-indexed-anywhere subjects?
> 
> I wonder how stored properties could potentially be implemented, I can only 
> think of two ways:
> 
> 1. An extra pointer per instance (with resulting ABI compatability 
> implications) to hold a collection of the stored items.
> 
> 2. A global lookup for any instance where stored properties have been set.
> 
> I'm not a language implementation expert, or familiar with the swift 
> implementation, so there may be other/better ways - I'd like to know if there 
> are?
> 
> If not, and option 2 was employed, a little foresight might enable the 
> mechanism to be overloaded in the future for other dynamic features too. A 
> bit flag (I'm hoping there's a spare bit in an existing flags field 
> somewhere?) could indicate whether any feature had caused the object to be 
> added to this lookup and deinit could check this bit and make sure the object 
> is removed, thus any stored properties are nilled. The lookup value could be 
> a struct with one member (extensionStoredProperties), and additional members 
> can be added in future for new features.
> 
> I get the impression from the associated objects discussion that perhaps 
> there are much better, more optimal, more ingenious, more unknown-by-me ways 
> of doing such things, so apologies if this whole idea is way-off the mark :D
> 
> Jay
> 
> P.S. Note that stored properties in extensions could enable developers to 
> implement their own dynamic features in Swift.. so such desires could be 
> satisfied in the short term until they could be done properly in the language.
> 
> On Sat, 1 Oct 2016 at 00:49 Chris Lattner via swift-evolution 
> > wrote:
> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution 
> > wrote:
> > Is it possible to have best of (these completely different) both worlds?
> 
> Yes, of course it is.  Your email spends a lot of words trying to form a 
> false dichotomy.  Swift can definitely have both awesome dynamic features 
> while still having performance, predictability and safety.
> 
> > Would it be possible in Swift to have facilities to generate objects
> > dynamically at runtime? and, if desirable, how can such be implemented?
> 
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection 
> 
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have 
> bandwidth to reevaluate this area from first principles, I’m sure we can 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

I have been thinking further on this and in addition to my previous two
thoughts about implementation, I have had another idea...

3. If there is a bit spare in the object header somewhere (that is
currently always zero), this could be used to signify the presence of an
additional struct that immediately follows after the existing object data.
I *think* that this method would allow binary compatibility with older
modules. Instances that have this bit set would allow stored properties in
extensions. The struct at the end would have one member, a pointer to a
table of additional objects/values, stored properties defined in extensions
could be stored in here, using a hash derived from the
module/protocol/extension/property name (or something better if it exists).

The struct could be very simple as described above or more complex, with
additional features, for example a list of deinit hooks, dynamically added
methods, etc. The struct itself may also be dynamic in size/layout if such
complexity is warranted by size or extensibility concerns. Perhaps it
should start with some flags and its size (size would be fixed and only
increase with revisions so this would double as a 'version' number).

If viable - this would be a much better way to implement this feature than
my previous two ideas. It doesn't require global lookups or additional
levels of indirection beyond accessing the dynamic data/feature itself.


On Mon, 3 Oct 2016 at 04:13 Jay Abbott  wrote:

> Are stored properties in extensions already being discussed elsewhere? Is
> this one of those deferred-but-not-indexed-anywhere subjects?
>
> I wonder how stored properties could potentially be implemented, I can
> only think of two ways:
>
> 1. An extra pointer per instance (with resulting ABI compatability
> implications) to hold a collection of the stored items.
>
> 2. A global lookup for any instance where stored properties have been set.
>
> I'm not a language implementation expert, or familiar with the swift
> implementation, so there may be other/better ways - I'd like to know if
> there are?
>
> If not, and option 2 was employed, a little foresight might enable the
> mechanism to be overloaded in the future for other dynamic features too. A
> bit flag (I'm hoping there's a spare bit in an existing flags field
> somewhere?) could indicate whether any feature had caused the object to be
> added to this lookup and deinit could check this bit and make sure the
> object is removed, thus any stored properties are nilled. The lookup value
> could be a struct with one member (extensionStoredProperties), and
> additional members can be added in future for new features.
>
> I get the impression from the associated objects discussion that perhaps
> there are much better, more optimal, more ingenious, more unknown-by-me
> ways of doing such things, so apologies if this whole idea is way-off the
> mark :D
>
> Jay
>
> P.S. Note that stored properties in extensions could enable developers to
> implement their own dynamic features in Swift.. so such desires could be
> satisfied in the short term until they could be done properly in the
> language.
>
> On Sat, 1 Oct 2016 at 00:49 Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Is it possible to have best of (these completely different) both worlds?
>
> Yes, of course it is.  Your email spends a lot of words trying to form a
> false dichotomy.  Swift can definitely have both awesome dynamic features
> while still having performance, predictability and safety.
>
> > Would it be possible in Swift to have facilities to generate objects
> > dynamically at runtime? and, if desirable, how can such be implemented?
>
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection
>
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have
> bandwidth to reevaluate this area from first principles, I’m sure we can
> make improvements on it.
>
> I will grant you that Smalltalk is a beautiful language in its simplicity,
> but for that simplicity it makes many tradeoffs that we’re not willing to
> make.  We are willing to make the internal implementation of Swift complex
> if that means that we get a beautiful model for programmers - one that
> preserves the virtues of safety-by-default, predictability, performance,
> and joy-to-develop-in.
>
> The meme of “Swift can never (or will never) support dynamic features” is
> tired, and also wildly inaccurate.
>
> -Chris
>
> ___
> 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Are stored properties in extensions already being discussed elsewhere? Is
this one of those deferred-but-not-indexed-anywhere subjects?

I wonder how stored properties could potentially be implemented, I can only
think of two ways:

1. An extra pointer per instance (with resulting ABI compatability
implications) to hold a collection of the stored items.

2. A global lookup for any instance where stored properties have been set.

I'm not a language implementation expert, or familiar with the swift
implementation, so there may be other/better ways - I'd like to know if
there are?

If not, and option 2 was employed, a little foresight might enable the
mechanism to be overloaded in the future for other dynamic features too. A
bit flag (I'm hoping there's a spare bit in an existing flags field
somewhere?) could indicate whether any feature had caused the object to be
added to this lookup and deinit could check this bit and make sure the
object is removed, thus any stored properties are nilled. The lookup value
could be a struct with one member (extensionStoredProperties), and
additional members can be added in future for new features.

I get the impression from the associated objects discussion that perhaps
there are much better, more optimal, more ingenious, more unknown-by-me
ways of doing such things, so apologies if this whole idea is way-off the
mark :D

Jay

P.S. Note that stored properties in extensions could enable developers to
implement their own dynamic features in Swift.. so such desires could be
satisfied in the short term until they could be done properly in the
language.

On Sat, 1 Oct 2016 at 00:49 Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Is it possible to have best of (these completely different) both worlds?
>
> Yes, of course it is.  Your email spends a lot of words trying to form a
> false dichotomy.  Swift can definitely have both awesome dynamic features
> while still having performance, predictability and safety.
>
> > Would it be possible in Swift to have facilities to generate objects
> > dynamically at runtime? and, if desirable, how can such be implemented?
>
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection
>
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have
> bandwidth to reevaluate this area from first principles, I’m sure we can
> make improvements on it.
>
> I will grant you that Smalltalk is a beautiful language in its simplicity,
> but for that simplicity it makes many tradeoffs that we’re not willing to
> make.  We are willing to make the internal implementation of Swift complex
> if that means that we get a beautiful model for programmers - one that
> preserves the virtues of safety-by-default, predictability, performance,
> and joy-to-develop-in.
>
> The meme of “Swift can never (or will never) support dynamic features” is
> tired, and also wildly inaccurate.
>
> -Chris
>
> ___
> 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