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

[Jay Abbott]

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 <griotspeak at gmail.com> 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161016/e808aade/attachment.html>