-1 for me, but... > I’m aware of how associated objects work, I’m not aware of why they are particularly useful in Swift
If stored properties in Extensions aren't useful, why would anything else in an Extension be useful either? I gather there are reasons it is impractical to implement them, but saying there's no benefit to them is like arguing against allowing methods in Extensions, or computed properties. My own reason for wanting stored properties in Extensions, is that it would allow me to organize my classes according to their features. I'm working on drag and drop at the moment, and I would find it much less confusing in future, if I could keep all the related properties and methods I'm creating isolated in a single file. It would also allow me to reuse the same View in other projects that don't require Drag and Drop *as is.* Otherwise, when I reuse the class, I'll have to either carry along stored properties I don't need, or carefully weed them out. > we have to do better than ObjC That's the reason I'm against the proposal, too. If we allow stored properties they should be first-class citizens (assuming that is technically possible, I don't understand enough about how Frameworks etc are compiled to know if it would cause issues). I already avoid Associated Objects because I worry the additional complexity will make my apps harder to debug if there are memory or performance issues, so the thought of baking them into Swift doesn't really appeal to me. On Wed, Sep 28, 2016 at 6:52 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > > 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 > > 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
