Proposal: Introduce User-defined "Dynamic Member Lookup" Types

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

···

on Date: Thu, 30 Nov 2017 17:54:19 -0600 Xiaodi Wu <xiaodi.wu@gmail.com> 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.

Correct me if I’m wrong, but to me it looks like the main objectives to this proposal are cleared once we make it either a DynamicObject (vs a dynamic protocol) or we restrict this protocol adoptions to be only possible from within the main body of types, so in no way it will be possible to retrospectively extend, say, NSObject to conform to this protocol. Cool.

About the only bit missing is autocomplete and other mentioned things like goto definition, indexing, etc... IMHO these are not that important... but ok, assuming they are... we have a precedent of image literals to effectively “autocomplete” UIImage(named: “string”), perhaps we can have a similarity machinery that can autocomplete the relevant python method names and check for the typos. all during compile time.

Mike