[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
mike.kluev at gmail.com
Fri Dec 1 04:24:32 CST 2017
on Date: Thu, 30 Nov 2017 17:54:19 -0600 Xiaodi Wu <xiaodi.wu at gmail.com>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution