[swift-evolution] associated objects

[Jay Abbott]

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'm not trying to make Swift more like Obj-C - far from it - I want Swift
to ditch all the Obj-C related stuff and be its own thing. It frustrates me
to see bad patterns in UIKit (for example) being present in UIKit-for-Swift
(I understand why of course, but it's annoying still). Also things like the
CharacterSet discussion in the other thread - to me it seems like some of
the Objective-C-related implementation details of Swift libraries are
leaking out (the language itself doesn't seem to suffer from this though).

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...

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.

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

On Fri, 30 Sep 2016 at 07:13 Brent Royal-Gordon <brent at architechies.com>
wrote:

> > On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution <
> 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>
>
> 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/716c6ec8/attachment.html>