[swift-evolution] [Pitch] Property reflection

[Matthew Johnson]

Sent from my iPad

> On May 27, 2016, at 8:25 AM, Charlie Monroe <charlie at charliemonroe.net> wrote:
> 
>> 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.
> 
> Not just deserialization, but also for example, if you take upon something like Swift version of CoreData, some vars may be private, but the framework will need access to them. Of course, this could be handled by some annotation giving access to the variable via reflection.

I believe CoreData uses synthesized computed properties that access values stored in an internal row cache (or something along those lines).

> 
> I'm in favor of reflecting all vars by default (even private ones) with an option to opt-out.

I much prefer the opt-in approach if we're going to allow for reflection to have different visibility.  Access control should be explicit IMO.

> 
> 
> 
>> 
>>> or property behaviors (I think get-set behavior is fundamental to properties, although "behavior metadata" on the views might be useful).
>> 
>> 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.
>> 
>>> 
>>> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/04c12365/attachment.html>