<div dir="ltr">Thanks, as always, for the thoughtful feedback. (inline)<div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br><div><br></div></span><div>These names are a good place to start but I agree that it would be nice to improve them. I will give it some thought. One comment for now - you use both `get` / `set` and `read` / `write`. It’s probably better to pick one.</div></div></div></blockquote><div><br></div><div>Yes, that's a good start. I'll sleep on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>What do you think of using the `deriving` syntax for this (assuming we go in that direction for Equatable, Hashable, and other synthesized conformances).</div></div></div></blockquote><div><br></div><div>'deriving' is pretty much what I had in mind. If Equatable gets a magical attribute, keyword, or whatever, I'd like to use it for this feature as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>How did you arrive at `get` and `set` methods?</div></div></div></blockquote><div><br></div><div>One big advantage methods have over properties is that you can (as of right now) get a reference to a method as a value of function type, but not a property.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>I am wondering how this might relate to lenses. If we’re going to introduce those it feels like the property value should be introduced as a lens. I’m unsure of exactly what that would look like but I it is definitely worth thinking about.</div></div></div></blockquote><div><br></div><div>I think it's worth consideration. Maybe views into properties can eventually conform to some sort of lens protocol or interface, allowing them to be composed and used as such.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div>Another option if we don’t go with a lens is a simple property (`var value { get }` and `var value { get set }`). IIRC we are going to have throwing computed properties eventually so you could still throw from the setter.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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), </div></div></div></blockquote><div><br></div></span><div>This one is tricky. I am generally be opposed to any way to get around access control. But people are going to implement things like serialization using this which may require access to private properties. I think we want to try to understand the consequences of different options and when in doubt decide in favor caution.</div></div></div></blockquote><div><br></div><div>My personal preference would be to honor access control, and consider ser/de separately (especially since there are so many other possible considerations for that feature). Access control in Swift isn't just another safety feature, it's also a boundary for things like the optimizer.</div><div><br></div><div>To be honest, I expect the first big use of a feature like this to be turning JSON or XML received from a network call into model objects for an app. There are quite a few Objective-C libraries that use KVC to implement this functionality.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div>or property behaviors (I think get-set behavior is fundamental to properties, although "behavior metadata" on the views might be useful).</div></div></div></blockquote><div><br></div></span><div>Not just behavior metadata. Someday we might have user-defined attributes which we would also want to have available. It’s probably better to make available anything that could be useful and isn’t too costly to provide. It could all live behind a `metadata` property so we don’t clutter the interface of the views themselves.</div><br></div></div></blockquote><div><br></div><div>Absolutely. It's not clear right now what property behaviors will end up looking like, but if possible I'd definitely like to reify them and expose them to the end user (like how the T.Type is exposed in the gist). At the very least (and this is definitely insufficient), there should be a list of strings describing the behaviors.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div><span class=""><div dir="ltr"><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></span>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div><br></div></div>