[swift-evolution] associated objects

[Jay Abbott]

Hey Karl,

Regarding your comment "It’s unfortunate that it can’t be made more optimal
from an implementation perspective" - I think that it can be done in an
optimal way, just that the language devs are focusing on other things at
the moment. I replied to this thread earlier, changing the subject to
"stored properties in extensions" because that's actually what is wanted
(associated objects is just one way to achieve it). I have some more to add
to that thread so I will continue there.

On Sat, 8 Oct 2016 at 12:19 Karl <razielim at gmail.com> wrote:

> On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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
>
>
> I think that being able to retroactively associate data with some other
> data is extremely important. It’s unfortunate that it can’t be made more
> optimal from an implementation perspective, but it simplifies so many
> problems were you would otherwise associate data by keeping parallel
> collections of indices or whatnot.
>
> I would like it if extensibility was built-in to types in Swift; that
> their internal layout reserved a pointer at the end, which could point to a
> dictionary or some other data.
>
> Really, when it comes to retroactive extensibility, it’s incredibly
> strange that you can add functions but not data. If we were inventing a
> language without caring about the implementation cost, we would be able to,
> obviously. I actually don’t think the cost is all that high, and perhaps
> there are ways that the compiler could still optimise it (perhaps assigning
> each value an index in an array, rather than a dictionary?).
>
> If we actually want Swift to be this amazing programming language which
> can scale from scripting to systems programming, we definitely need a way
> to arbitrarily tag objects. Lots of people won’t use it, and that’s fine,
> but there are times when you really need it and in those cases you wish you
> were using a different language.
>
> Karl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161009/d969e9e9/attachment.html>