Flatten the Interaction types down to a single Interaction protocol.

Authored by featherless on Mar 9 2017, 1:55 AM.



This new protocol is abstract over the target type, T. This diff flattens ViewInteraction and PropertyInteraction into a single protocol, greatly simplifying the overall type system and also making it possible for interactions to support novel target types.

This change introduces a feature regression: interactions can no longer support multiple target types via overloads. In practice, I found that this actually cleaned up runtime.add call sites (e.g. springs can't be added to views anymore, they must be explicitly added to a property), so I'm not particularly concerned about this regression.

If we do find that it's important for an interaction to support multiple distinct target types, then we can introduce variant Interaction types, e.g. InteractionVariant1, InteractionVariant2, etc... with corresponding runtime APIs.

Diff Detail

rREACTIVEMOTIONSWIFT reactive-motion-swift
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
featherless created this revision.Mar 9 2017, 1:55 AM
chuga accepted this revision.Mar 10 2017, 11:48 AM
chuga added a subscriber: chuga.
chuga added inline comments.

just curious, why isn't this [Interaction]?

This revision is now accepted and ready to land.Mar 10 2017, 11:48 AM
featherless added inline comments.Mar 10 2017, 11:59 AM

Because Interaction is a generic protocol. Arrays expect that they'll have a predefined shape, so we'd need to create an AnyInteraction class here that provides a concrete sub-type.

Given that this is a private variable I'm not particularly concerned about ensuring type correctness here, so opted to just use the Any type.

This revision was automatically updated to reflect the committed changes.