<div dir="ltr"><div>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?<br><br>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, 16 Oct 2016 at 23:31 T.J. Usiyan <<a href="mailto:griotspeak@gmail.com">griotspeak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">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. </div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"></div></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Greg:<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">Benjamin:<br class="gmail_msg"><br class="gmail_msg">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 <a href="https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html" class="gmail_msg" target="_blank">https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html</a> for a detailed discussion).<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg"></div>Haravikk:<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It can be done efficiently using Greg's proposed changes. The current implementation on his branch (<a href="https://github.com/gparker42/swift/tree/new-refcount-representation" class="gmail_msg" target="_blank">https://github.com/gparker42/swift/tree/new-refcount-representation</a>) 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.<br class="gmail_msg"><br class="gmail_msg"></div>Anton:<br class="gmail_msg"><br class="gmail_msg"></div>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?<br class="gmail_msg"></div><br class="gmail_msg"></div>
<br class="gmail_msg"></blockquote></div></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div></blockquote></div>