[swift-evolution] associated objects

[Robert Widmann]

> On Sep 30, 2016, at 9:40 AM, Jay Abbott <jay at abbott.me.uk> wrote:
> 
> Robert,
> 
> What it does is allow developers to extend the language to do things that it doesn't support. Associated Objects is just a flexible way to allow developers to do that, and that's how I used it in Objective-C, so that's what I thought of in Swift when I found that "I want to do <x> but the language doesn't support it". Maybe there's a completely different way to achieve the same thing - but I just went with what I know.

"I want to do <x> but the language doesn't support it” is the whole reason for this list!  I want to know what “<x>” 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.


> So it's difficult to come up with concrete examples of "things a developer might want to do but the language doesn't support" because almost by definition they are unforeseen. I can only enumerate the things I have wanted to do in Obj-C and Swift and how I got around it.
> - Dynamically add properties to a class (obc-c) / implement stored properties (swift).
> - Add per-instance methods at run-time.
> - Perform a function when some other object is deallocated (haven't solved this in Swift yet, but in obj-c associated object deallocation is well-defined so I used that).
> - Other unforeseen things…

Again, these are features and I want motivations behind them.  Why should you be able to dynamically add stored properties and methods to any Swift class?  Why 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).

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.

> 
> So maybe Associated Objects isn't the answer and I should have stated the problem better, instead of jumping to what I thought the answer might be... the problem I want to solve is this:
> 
> As a developer I want to do <x> but the language doesn't support it... what helpful thing *can* I use right now that allows me to achieve this? I accept the disclaimer by ticking this box:
> [ ] Yes, I understand that I'm not using Swift anymore, but some custom run-time thing that I'm building myself on top of Swift, so if I want type safety I have to implement it, if I want copy-on-write or other optimisations, I have to implement it, and I understand that performance might not be the best too.
> 

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.  

> If Swift can provide something to help developers go beyond the abilities the current version, isn't that a good idea?

No one disputes this.  We just want to see your rationale.

> 
> On Fri, 30 Sep 2016 at 07:13 Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
> > On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > To make this kind of pattern type safe you would, for example, need to keep track metatype pointers too and use the dynamic cast machinery to check the type on retrieval.
> 
> Actually, a somewhat different (DispatchSpecificKey-style) design makes type safety pretty easy:
> 
>         import Cocoa
> 
>         let myValue = AssociatedValue(.strong, ofType: String.self, on: NSView.self)
> 
>         let view = NSView()
>         myValue[view] = "Hello, world!"
>         myValue[view]
> 
> Implementation here: <https://gist.github.com/brentdax/75bfd619379fea53d8ca8afaa16d95bb <https://gist.github.com/brentdax/75bfd619379fea53d8ca8afaa16d95bb>>
> 
> Nevertheless, I don't think this should be shipped in Swift; associated objects are as esoteric as they come.
> 
> --
> Brent Royal-Gordon
> Architechies
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160930/f862c535/attachment.html>