<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 7:42 PM, Callionica (Swift) <span dir="ltr"><<a href="mailto:swift-callionica@callionica.com" target="_blank">swift-callionica@callionica.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Callionica</div></font></span><div class="HOEnZb"><div class="h5"><div><br>On Thursday, May 26, 2016, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi swift-evolution,<div><br></div><div>For those who are interested I'd like to present a pre-pre-proposal for reflection upon a type's properties and solicit feedback. </div><div><br></div><div>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 <i>defending</i> this specific proposal per se, as I am looking for a jumping-off point to explore designs in this space.</div><div><br></div><div>Anyways, here is a gist outlining the public API to the feature: </div><div><br></div><div><a href="https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a" target="_blank">https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a</a><br></div><div><br></div><div>A couple of notes regarding the proposal:</div><div><br></div><div>The API names need improvement. Suggestions welcome.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>```</div><div>myPerson.typedReadWriteProperty<Int>("age")?.set(30)</div><div><br></div><div>try myPerson.allNamedProperties["age"]?.set(30)</div><div>```</div><div><br></div><div>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).</div><div><br></div><div>I'd also have to figure out how it would operate with generic types or existentials.</div><div><br></div><div>Anyways, thanks for reading all the way to the end, and any feedback, criticism, or alternative proposals would be greatly appreciated.</div><div><br></div><div>Best,</div><div>Austin</div></div>
</blockquote></div>
</div></div></blockquote></div><br></div>