> 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)
                …
        }

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to