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

[T.J. Usiyan]

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/115754b1/attachment.html>