> On May 27, 2016, at 9:57 PM, Brent Royal-Gordon via swift-evolution 
> <[email protected]> wrote:
> 
>> I'm not sure how this alternative is related to access control.  Austin's 
>> proposal could enforce access control in the same way and he mentioned he 
>> was inclined to enforce it the same way you are describing.
>> 
>> The reason I say it is tricky is because enforcing access control in this 
>> way would prevent things people want to do with reflection (things that have 
>> received a lot of discussion recently).  Allowing a distinct visibility to 
>> be specified for reflection might be a way to strike a reasonable balance.
> 
> It's related to access control because it's specifically intended that you 
> can pass your `properties` dictionary to other code to delegate your access. 
> This works around the "but other code needs to see your private stuff" 
> problem: it *can* see your private stuff, but only if you permit it.
> 
> I suppose we would want a `#properties` you could use in a protocol 
> conformance which would mean "the properties visible at the conformance site":
> 
>       protocol Serializable {
>               var propertiesToSerialize: PropertyView<Self> { get set }
>               init(forDeserialization: ())
>       }
>       extension Serializable {
>               var propertiesToSerialize: PropertyView<Self> {
>                       get { return #properties }
>                       set { #properties = newValue }
>               }
> 
>               func serializedData() -> Data {
>                       return Serializer().serialize(self)
>               }
>               factory init(serializedData data: Data) {
>                       self = Serializer.deserialize(data, of: Self.self)
>               }
>       }
> 
>> Your suggested approach doesn't allow for access to property metadata.  Do 
>> you have any suggestions on how that would be exposed?  
> 
> I'm not sure how much metadata is necessary beyond name (in the key) and type 
> (discussed soon).
> 
>> What about casting the lens to a typed lens?  Would you envision that being 
>> supported?
> 
> Yes. I would hope that you could downcast a concrete lens:
> 
>       let lens: () -> inout Int = &array.count                                
>         // Assuming this is a "get lens" syntax
>       let abstractLens = lens as () throws(set) -> inout Any          // 
> Upcasting an inout-returning function adds `throws(set)`
> 
> And that you could later open the abstracted lens to get its concrete type:
> 
>       if let concreteLens = abstractLens openas Lens {
>               print(Lens.ReturnValue)
>               …
>       }


wonder what that means... if I recall, the idea of openas is that one knows the 
'contained type', not that it is some kind of reflection that lets you discover 
it at runtime, right?! 


> 
> This is a slightly different form of existential opening, and `ReturnValue` 
> doesn't currently exist on function types, but I hope these things would be 
> possible.     
> 
>> I also think we would want a way to access a specific property by name if 
>> accessing the whole properties dictionary involved any non-trivial overhead 
>> (but maybe it wouldn't have to).
> 
> That's why I said "like a dictionary". :^) If there's a way to access 
> individual keys without collecting them all ahead of time, or to generate 
> lenses as needed, I'm all for it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to