[swift-evolution] associated objects

[Jay Abbott]

Hey Robert,

Well the example I gave was stored properties in extensions - that is they
can be easily implemented as calculated properties that actually use
associated objects/values to store their value. The other one is
per-instance actions, programmers can dynamically add an action (closure)
to any instance (for example decide where it needs to be sent and add a
closure with the key "send"), then that action can be performed later by
retrieving whatever is in "send" and calling it - basically whenever
functionality rather than data needs to be moved around.

I agree it's not an efficient or type-safe system, but of course any
developer using it is doing so at run-time so they know there's no
type-checking going on and should take measures to ensure only the correct
types are put into any situation (or check it themselves). It *can* be
implemented without affecting the ABI - as my example code shows, I'm just
not sure if this is a good way to do it.

I'm not sure what you mean about obj-c associated objects having a slow
deallocation path, is there a learning-point from the obj-c implementation
that helps here? If so I don't know it :) I don't think you would try to
make it type-safe as it's a dynamic feature and you'd expect the users to
do that themselves - sure there could be ways to use reflection to help
out, but is this necessary?

As noted in the README - deinit hooks would enable an implementation that
doesn't need to do the internal clean-up. So it works as-is, but could be
improved with some language features.


On Wed, 28 Sep 2016 at 19:46 Goffredo Marocchi <panajev at gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Have you got a significant use-case for this that absolutely can't be
> solved by extensions or subclassing?
>
> This does have ABI impact but more concerning for me is the performance
> impact and that the existing API is not type safe.
>
> Using associated objects in ObjC gets you read through the slowest
> possible deallocation paths and means the runtime is effectively tracking
> an extra table of pointer tables per object-with-associations.  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.
>
>
> If observers, whose lifetime is longer than the the observed objects' one,
> were notified when the observed object is deallocated then I would agree
> with you about safety concerns trumping usability... but as it is right now
> a nice mechanism like KVO is made trickier to use than it should be without
> associated objects (KVO leakage is quite a scary concept :)).
>
>
> ~Robert Widmann
>
> 2016/09/28 11:26、Jay Abbott via swift-evolution <swift-evolution at swift.org>
> のメッセージ:
>
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects
>
> The README is very short and straight-forward so I won't re-describe it
> here.
>
> The implementation isn't great, but it's a small and simple proof of
> concept. I have further extended this (not in GH, but very simple and happy
> to share if anyone cares) to add dynamic methods using closures onto
> individual object instances. Useful for user interactions, or adding
> 'actions' to objects.
>
> I'd like to propose that this or something similar be added to the
> standard library. It could potentially even be added to AnyObject so that
> developers can use it without having to declare an extension for whichever
> classes they want to use it on.
>
> As mentioned, this can easily be extended (either in the standard library
> or by developers) to add closures dynamically to any object, or to any
> class, which could serve as a useful way for those not concerned with type
> safety and the like to get some dynamic behaviour in there in the shorter
> term. With a little language support it could even be used to implement
> stored properties in extensions very easily.
>
> A better implementation would need some language changes - specifically
> deinit hooks (has that ever been discussed?) because of the way weak
> references are lazily zeroed. Another implementation improvement might
> lazily add the dictionary to each object instead of storing it globally -
> not sure if this would have ABI implications.
>
> Interested in feedback and thoughts :)
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160928/5d0c04cd/attachment.html>