<div dir="ltr">on Date: Thu, 30 Nov 2017 17:54:19 -0600 Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Alternatively--and perhaps more elegantly--we could address this concern<br>
head-on by having, instead of `DynamicMemberLookupProtocol` and<br>
`DynamicCallable`, a magical class `DynamicObject` which all dynamic types<br>
must inherit from. It would then be clear by design that Swift types cannot<br>
be _retroactively dynamic_ in the sense that Chris proposes. I *think* the<br>
vast majority of bridged use cases can tolerate being `final class` types<br>
instead of `struct` types. I could be wrong though.<br>
<br>
Now, as to the possibility of failure: I agree also that eliding the<br>
possibility of lookup failure at the callsite requires further<br>
consideration. Some might agree that restricting dynamic features only to<br>
subclasses of a `DynamicObject` might be clear enough that we do not need<br>
to go further in this regard. </blockquote><div> </div><div>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.</div><div><br></div><div>Mike</div><div><br></div></div></div></div>