[swift-evolution] [Pitch] Property reflection

L Mihalkovic laurent.mihalkovic at gmail.com
Fri May 27 18:25:14 CDT 2016


> On May 27, 2016, at 9:57 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list