> On Sep 30, 2016, at 9:40 AM, Jay Abbott <j...@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 <br...@architechies.com 
> <mailto:br...@architechies.com>> wrote:
> > On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@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
> 

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to