Thank you! If you have other ideas I'd love to hear them, even if they're completely different. I think this is a topic that deserves to 'simmer' for a while.
You bring up an important point: should reflection be opt-in or opt-out? I've seen arguments for both options, and I think it's definitely a point that needs to be very carefully discussed. Importantly, opt-out makes this a sort-of-zero cost abstraction; only types that need the functionality take the performance and metadata size hit. This is something that the core team seems to find important. If it is opt-in, though, there are certainly a bunch of framework base types that should be opted-in, so that all their subclasses can be reflected upon, providing most of the practical benefits of default opt-in. Giving UIView and NSView this functionality would be a starting point, and *maybe* NSObject (although that would have effects upon all of Swift Foundation). Best, Austin On Thu, May 26, 2016 at 7:42 PM, Callionica (Swift) < [email protected]> wrote: > This is important and really useful. There's a lot to like here. I have > been thinking about property reflection recently too. Don't have time to > write too much on it now, but was wondering what was the thinking behind > suggesting an opt-in? For me, I would hope that getting access to a > single property object that holds the getter and setter functions would > be almost as simple as the way we obtain a function reference for a method > (by naming the item in code) and would hope that it would work for all > types. > > -- Callionica > > On Thursday, May 26, 2016, Austin Zheng via swift-evolution < > [email protected]> wrote: > >> Hi swift-evolution, >> >> For those who are interested I'd like to present a pre-pre-proposal for >> reflection upon a type's properties and solicit feedback. >> >> First of all, some caveats: this is only a very small piece of what >> reflection in Swift might look like one day, and it's certainly not the >> only possible design for such a feature. Reflection comes in many different >> forms, and "no reflection" is also an option. Deciding what sort of >> reflection capabilities Swift should support is a prerequisite to >> stabilizing the runtime API, which I imagine has resilience consequences. >> I'm not really interested in *defending* this specific proposal per se, >> as I am looking for a jumping-off point to explore designs in this space. >> >> Anyways, here is a gist outlining the public API to the feature: >> >> https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a >> >> A couple of notes regarding the proposal: >> >> The API names need improvement. Suggestions welcome. >> >> It's opt-in: types have to conform to a special protocol for the compiler >> to generate whatever hooks, metadata, and support code is necessary. Once a >> type conforms, the interface to the reflection features naturally present >> themselves as protocol methods. It would be great to allow an extension to >> retroactively enable reflection on a type vended by another module, >> although I have no idea how feasible that is. >> >> It uses "views": there are four types of views, two of each in the >> following categories: typed vs untyped, get-only versus get-set. A view is >> a struct representing a property on an instance of a type (or maybe a >> metatype, for type properties). It allows you to get information about that >> property (like its name) and try getting and setting its values. >> >> (You can get a get-only view to a property, and then try and upgrade it >> later to a get-set view, if the underlying property is get-set. If you >> don't care about setting, though, you can just work exclusively with >> get-only views.) >> >> It supports both typed and untyped access. You can ask for a property >> view specifically for (e.g.) a `String` property, and if you get one you >> can be assured that your getting and setting operations will be type safe. >> You can also ask for an "untyped" property view that exposes the value as >> an Any, and allows you to try (and possibly fail, with a thrown error) to >> set the value. >> >> The requirements part of it is composable. For example, you can imagine a >> future "FullyReflectable" protocol that simply inherits from >> "PropertyReflectable", "MethodReflectable", and other reflectable >> protocols. Or maybe a library requires reflection access to types that it >> needs to work with, and it can create its own protocols that inherit from >> "PropertyReflectable" and naturally enforce reflection support on the >> necessary types. >> >> It looks a bit cumbersome, but there's room for refinement. Users won't >> necessarily see all the types, though, and the interface is pretty >> straightforward: >> >> ``` >> myPerson.typedReadWriteProperty<Int>("age")?.set(30) >> >> try myPerson.allNamedProperties["age"]?.set(30) >> ``` >> >> I'm not yet sure how it should interact with access control (my >> inclination is that it would only expose the properties you'd be able to >> directly access), or property behaviors (I think get-set behavior is >> fundamental to properties, although "behavior metadata" on the views might >> be useful). >> >> I'd also have to figure out how it would operate with generic types or >> existentials. >> >> Anyways, thanks for reading all the way to the end, and any feedback, >> criticism, or alternative proposals would be greatly appreciated. >> >> Best, >> Austin >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
