[swift-evolution] associated objects

[Jay Abbott]

On Fri, 30 Sep 2016 at 15:41 Robert Widmann <devteam.codafi at gmail.com>
wrote:

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

I know, and appreciate this, thanks :) I'm not easily offended and I prefer
to be wrong in a room full of smarter people than right (or think that I'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!


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

If I'm using an existing framework such as UIKit, and I want to add
something it doesn'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.

There's probably a much better way to express the above in the abstract -
sorry I suck at that :)

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

It'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'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).

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

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'd implement it using stored properties.

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

I guess you're right - it's really stored properties in extensions that I
want...  but actually - what's the difference? Aren't they basically the
same thing? :)

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