on Date: Thu, 30 Nov 2017 17:54:19 -0600 Xiaodi Wu <[email protected]> wrote:
> > Alternatively--and perhaps more elegantly--we could address this concern > head-on by having, instead of `DynamicMemberLookupProtocol` and > `DynamicCallable`, a magical class `DynamicObject` which all dynamic types > must inherit from. It would then be clear by design that Swift types cannot > be _retroactively dynamic_ in the sense that Chris proposes. I *think* the > vast majority of bridged use cases can tolerate being `final class` types > instead of `struct` types. I could be wrong though. > > Now, as to the possibility of failure: I agree also that eliding the > possibility of lookup failure at the callsite requires further > consideration. Some might agree that restricting dynamic features only to > subclasses of a `DynamicObject` might be clear enough that we do not need > to go further in this regard. this might be a good compromise indeed. along with PythonObject subclass, RubyObject subclass, etc. and eventually even "backporting" NSObject to be a subclass of DynamicObject and using this same infrastructure. Mike
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
