<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Fri, 30 Sep 2016 at 15:41 Robert Widmann &lt;<a href="mailto:devteam.codafi@gmail.com">devteam.codafi@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div><div style="word-wrap:break-word"><div><div>&quot;I want to do &lt;x&gt; but the language doesn&#39;t support it” is the whole reason for this list!  I want to know what “&lt;x&gt;” is in order to wrap my head around your proposal better.  I’m not here to invalidate your work with a slew of criticisms, I’m just trying to understand your proposal by probing you about it.</div></div></div></blockquote><div><br></div><div>I know, and appreciate this, thanks :) I&#39;m not easily offended and I prefer to be wrong in a room full of smarter people than right (or think that I&#39;m right when maybe not) in a room full of not smarter people. But I do struggle to articulate this without patronising everyone by explaining how I think it is (in order to be corrected) all the time. Hope that even makes sense!<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><div>Again, these are features and I want motivations behind them.  <i>Why</i> should you be able to dynamically add stored properties and methods to <i>any</i> Swift class?  </div></div></div></blockquote><div><br></div><div>If I&#39;m using an existing framework such as UIKit, and I want to add something it doesn&#39;t support, like drag+drop to all UIViews for example, then my implementation might want to use stored properties to help keep track of drag+drop-related config and state (isDraggable, isDropTarget, sourceView, etc.). This way I can extend UIView and use the stored properties from my extension methods, while keeping all the functionality of all its subclasses.<br></div><div><br></div><div>There&#39;s probably a much better way to express the above in the abstract - sorry I suck at that :) <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><i>Why</i> should you be able to observe deallocation if deallocation calls are not guaranteed (remember, Objective-C and Swift do not guarantee -dealloc/deinit calls in any order at any time - please don’t assume an RAII-like model because it will lead to memory leaks and malformed code).</div></div></div></blockquote><div><br></div><div>It&#39;s not deallocation, but deinit that would be useful. My motivation in Swift for wanting this was to get around lazy weak reference zeroing in my associated objects implementation. If the object is deinited, you can&#39;t ask it for an associated object, therefore its weak reference in my implementation would never be accessed so it would hang around forever. I got around that with a horrible clean-up hack that accesses the weak references just to ensure they get zeroed, so I wanted non-lazy zeroing (or a deinit hook).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>I will say: Perhaps if you’re having trouble motivating the inclusion of this feature, you may want to step back and reevaluate its place in the language and why you wanted to write this library in the first place.  Often times, I find that really helps get the creative juices flowing.  Or, if I can’t come up with anything, it means I go back to step 1 and start over.  Proposals can be as much a learning process for us as it is for you.</div></div></div></blockquote><div> <br></div><div>I know exactly why I wanted associated objects - to implement a) stored properties in extensions; and b) per-instance actions. If stored properties were available in extensions then I would not need it at all: a) I would already have it; b) I&#39;d implement it using stored properties.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>So from what I’ve gathered you’ve written a library to do this yourself.  You have a vision for how you want to use this library.  You think that vision is compatible with a language-level change.  From my perspective, your job now is to articulate that vision and motivate it to this list.  I don’t think associated objects and the other dynamic features you mention are fundamentally incompatible with Swift, I just think the design that I’ve seen so far may not be the best way of going about it and I’m voicing my concerns as much.<br></div></div></div></blockquote><div><br></div><div>I guess you&#39;re right - it&#39;s really stored properties in extensions that I want...  but actually - what&#39;s the difference? Aren&#39;t they basically the same thing? :)<br><br></div><div>J<br></div></div></div>