> On Sep 28, 2016, at 11:26 AM, Jay Abbott via swift-evolution > <swift-evolution@swift.org> wrote: > > I have implemented Associated Objects (and values) in pure swift here: > https://github.com/j-h-a/AssociatedObjects > <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.
I’m not convinced by this explanation. You haven’t shown me any cases where this feature is absolutely necessary, merely enumerated features. I’m aware of how associated objects work, I’m not aware of why they are particularly useful in Swift and I’d like to be given something to the contrary. As for the point about dismissing type safety: There is no precedent in the language for type-unsafe operations to be exposed wholesale to the end user like this. At the very least you should tag the API as Unsafe Associated Objects and now you’re stuck explaining why you’d like to stick a completely unsafe feature into a language that touts “Safety by Default”. It feels like pining for the Objective-C days of old, and I happen to think that that’s fine, but we have to do better than ObjC, not have features for the sake of features. > > 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. > That kind of implementation would be space-inefficient - all Swift classes now automatically incur an extra pointer-sized allocation per instance. It absolutely has ABI implications too because now we have to track an extra part of the header for an object and standardize on access patterns for the associated objects table. > Interested in feedback and thoughts :) > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
