Dynamic method replacement

Evolution Pitches
20

You all know I'm very much on the side of "library author should be in control" (cf. past support for the open/public distinction). For that reason, I'm strongly, strongly against any default replaceability. Given that, what is this proposal for? "When would a library author use this?" is a very good question. And I can think of a handful of answers:

  • A family of libraries that work well together: library Base exposes a dynamic entry point, and library Advanced adds some additional behavior. (This could be from the same vendor, or just an open extension point of some kind. It's probably not the long-term solution we want for registration, but you could implement that.)

  • Dynamically synthesized wrapper code, like KVO. The proposal Arnold's written here doesn't have syntax for that, but it probably has all the run-time underpinnings unless the runtime assumes that the implementation will never change after the first use. I do think it's probably an important use case, though, and even if we don't provide it now we should keep it in mind.

  • Testing, potentially. I'm not sure how I feel about this one, but people have been asking for simpler mock objects than "just do everything in terms of a protocol", and this might be one way. However, we probably wouldn't want to use the normal dynamic modifier for this; either we'd want something special or we'd want to have -enable-testing make everything dynamic. I'm not sure of the performance implications of that.

I'm also wary of anything that requires static initializers to do correctly, since Swift has been trying very hard to get away from them. But it sounds like we have ideas there.

I'm not sure why this is limited to members of types. Any reason why top-level functions and computed properties can't be dynamic?

One last thing: I don't like integer priorities; they run into the "what if two people did this" problem. IM(H?)O we should just say "if two libraries do this, both replacements are applied one on top of another; if library A links to library B, library B's replacement will be the 'inner' one". (Or the other way around. That can be a sub-discussion.)

10 Likes