> Hi everyone. Chris stole my thunder already—yeah, I've been working on a > design for allowing properties to be extended with user-defined delegates^W > behaviors. Here's a draft proposal that I'd like to open up for broader > discussion. Thanks for taking a look!
This is fantastic, Joe. The one big thing I would like to see from this feature is a way to get all the instances of a particular behavior which were attached to an instance. For example, I’d like to be able to annotate particular values with a `serialized` behavior and then have a serialization framework be able to access all the type’s `serialized` behavior instances and get or set the corresponding properties. Perhaps there’s a way to hack this in with what you’re doing already, but if so, I don’t see it yet. Relatedly, it would be nice if a behavior got the name of the property and type it was being applied to. In addition to my serialization case, this would be useful for error messages and probably some other things. It’s awesome and important that you can add arbitrary blocks like `didSet`, but I don’t see any mechanism to pass in any other sort of arbitrary parameter to a behavior. It’d be nice if you could do that. Okay, time for bikeshedding: I would really like to see this get the @ syntax. And specifically, I would like to see the @ syntax eventually *only* be used for behaviors and other user-extensible features like it, while anything that's pure, unalloyed compiler magic (like access modifiers) becomes a plain keyword. Obviously this would require some reorganization of existing features, and perhaps you wouldn’t do this all at once, but currently the @ syntax is not really used in any sort of principled way, and this seems like a good way to clean it up. If you do adopt @ syntax, then the behavior instance could be accessed with propertyName@behaviorName. I actually think that behavior instances should probably be private, and there should be no way to change that. Behaviors are inherently an implementation detail, and you should not be exposing them directly to users of your type. Instead, you should expose just the operations you expect to be needed through your own calls, which you can reimplement as needed. (This statement is not 100% compatible with my request for type-wide metadata, of course. Not sure how to reconcile those.) Overall, great work! I can already tell that I’m going to use the shit out of this feature. Now to read Kevin Ballard’s monster reply… -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
