[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[BJ Homer]

> On Dec 7, 2017, at 10:16 AM, Benjamin G <benjamin.garrigues at gmail.com> wrote:
> 
> 
> 
> On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer <bjhomer at gmail.com <mailto:bjhomer at gmail.com>> wrote:
> Benjamin, 
> 
> It sounds like your concern is that people might write objects that just store everything in a dictionary, instead of declaring typed properties. Correct?
> 
>> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I think i answered that question many times as well (by masquerading dictionaries as regular classes), but if what i'm saying is simply impossible because of Swift type system even with the new proposal, i'd rather people tell it to me than ask the same question over and over..
>> 
>> _______________________________________________
> 
> It would be possible, in theory, to write a class that used a dictionary as a backing store for all its properties under this proposal. However, the dictionary would have to be typed [String: Any?], and every property access would be typed Any?. Your code would look like this:
> 
> class MyDynamicObject: DynamicMemberLookupProtocol {
>     var storage: [String: Any?] = [:]
>     
>     subscript(dynamicMember: String) -> Any? {
>         get { return storage[dynamicMember] }
>         set(newValue) { storage[dynamicMember] = newValue }
>     }
> }
> 
> let x: MyDynamicObject = ...
> 
> // setting properties is easy!
> x.name <http://x.name/> = “Benjamin”
> x.age = 3
> 
> // using them, though, is hard!
> var adults: [String] = []
> if x.age as! Int > 18 {
>     adults.append(x.name <http://x.name/> as! String)
> }
> 
> If you decide to create an object that stores everything in an ‘Any’, Swift is going to force you to use an ‘as’ cast anytime you want to use it. That’s super annoying.
> 
> So yes, it’s possible to create a type that masquerades a dictionary as a regular class. But the ergonomics of doing so are sufficiently frustrating that nobody is likely to do so. Swift makes it easy to declare typed variables here, and the user experience for doing so is vastly improved (code completion, compile-time checking, no more ‘as’ casting, etc).
> 
> So while it’s theoretically possible to do this, I don’t think it’s a concern in practice. The incentives are already in place to encourage doing the “right” thing in this case, even with the possibility of dynamic member lookup.
> 
> -BJ
> 
> Hey, thanks for answering that part of the concern. i also came to this point, but wondered if the dictionary couldn't be made of type [String: DynamicValue] where DynamicValue would have some way to be  automatically casted to string, int, etc, by reusing the same mechanism that the proposal would use to convert PyVal to regular swift types. I stopped at this point.
> 


As far as I am aware, the proposal provides no mechanism for automatically converting back from PyVal to regular Swift types. You would have to do something explicit like myPythonValue.intValue, or String(myPythonValue).

-BJ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/95deb1f8/attachment.html>