[swift-evolution] [Pitch] Property reflection

[Callionica (Swift)]

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 <
swift-evolution at swift.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/507c142b/attachment.html>