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.
on Date: Thu, 30 Nov 2017 17:54:19 -0600 Xiaodi Wu <firstname.lastname@example.org> 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.