The Case for Message Passing in Swift

> I have filed a radar (Open Radar) asking for an eval() function in Swift.

Does anyone else thing that is a really bad idea in general? To do that not only would type safety go straight out of the window but so would a great many of the compile time optimisations that are currently possible (I don't know how many are being done at this time).

Within pure swift the type information can be statically checked at compile time and then the type information can essentially be discarded. To offer eval I don't think that would be possible. It is also probably why there isn't the level of reflection that the OP is wishing for.

This seems more like a case against message passing.

The reason iOS is smooth and fast is that a lot of the heavy lifting is done by optimized pure C code called from objective-C.

A major goal for Swift is to let people achieve that kind of performance without having to write the high performance stuff in C. C is replaced with swift's functional core. Switching all dispatch to message passing would destroy this benefit and push more development back into C.

The case of the Latin Conjugation, and the IRC client are terrible reasons for using message passing. Both are trivially solved with data structures and closures. It seems that the author has little experience with functional programming, and just wants to stick with Objective-C.

I'm not against message passing - I just think that Swift gets the balance right, and it would take a much stronger argument than this to justify message passing everywhere.

Honestly a lot of the cases presented here would be accomplished by a robust reflection API and some form of dynamic method compilation.

These are both things I haven't seen in Swift yet and will miss dearly from .net/C#.

What this post calls "message passing" should actually be called "dynamic dispatch" (http://en.wikipedia.org/wiki/Dynamic_dispatch). The term "message passing" is currently more often used as a certain way to do concurrency, and this post is not about concurrency at all.

The post is basically criticizing Swift for being static language, and not dynamic like Obj-C.

I wonder if the maxim about premature optimization needs to be considered more in language design.

For example - I want to write idiomatic Python with all the benefits of flexibility and readability. I then want the possibility of optimizing some parts to the level of a static language - but only those parts that need it.

The javascript performance battle is very revealing here though - it's surprising that asm.js hasn't got quite the clear lead one might expect.

Message swizzling/monkey patching is a hack that tries to deal with the reality of not being able to modify base classes you don't have the source code for and creates all sorts of surprise bugs.

If objective-c had proper support to do it via categories that can 'over-ride' methods it would be a lot cleaner in general.

Here's a very quick summary of the reasons cited in this article:

1. Mock objects

There's two different types of mocking. The first is where you know ahead of time what you need to mock, and this type is largely equivalent to just subclassing the desired class (except any methods called directly or indirectly by the class itself will bypass the mock). This could be achieved by implementing basically implicit delegation, where the invocation of any methods that an object does not respond to will be replaced by the same invocation on a designated property of the object. This could in fact be achieved today with conversion routines (which are undocumented and technically unsupported, so file a radar if you want to keep them), except when testing the object for its class or protocol support. So the language would have to add special support for this in order to have a true proxy object that pretends to be an instance of the target class.

The second is dynamic mocking, where you add behavior to the mock object at runtime. This I believe is what OCMock is doing. It's effectively equivalent to implementing every single method of the target class, and looking up any invocations of the method in an internal table of closures, falling back to calling the target class's implementation if there is no internal closure. Again, this would need support for class/protocol testing. And again, the language could certainly add support for this without message passing, by basically generating the code for what I just described.

It seems reasonable to me to request support for mock objects itself, without requiring message passing.

2. Swizzling

I'm really _really_ glad Swift's class model does not allow for this. Granted, you can still monkeypatch it at runtime the same way you can patch C code, but it's hard enough and esoteric enough that people will generally not do it.

Swizzling is a really bad idea. Every example given for why the author wants Swizzling is an example of something that you should not do. Changing Frameworks behavior, or injecting into apps and changing app behavior, is a Bad Thing™. When allowed, it's a major source for instability and crashes, and other bad behavior. For example, recently there's been a big resurgence in interest in unauthorized Xcode plugins, but Xcode doesn't have plugin support for a reason. Xcode plugins are a great way to make Xcode behave badly or crash. For example, Spark Inspector[1] installs an Xcode plugin on first launch (without asking!) that adds a menuitem to Xcode. And when Xcode 5.0 came out, it started crashing on launch for people who had the Spark Inspector plugin installed. And I guarantee you most people who experienced the crash did not know it was Spark Inspector's fault and blamed Xcode.

[1]: http://sparkinspector.com

Similarly, GPGMail is a Mail.app plugin that adds GPG support. Mail actually has official plugin support, although I believe it's pretty limited, and GPGMail ends up swizzling a bunch of stuff in the Compose window. Right now on OS X 10.10 Yosemite, GPGMail causes Mail.app to crash because of the swizzles (yes it's a beta OS, but the crash is entirely the fault of GPGMail, not the beta OS).

Simply put, swizzling is a horrible runtime hack that is possible in Obj-C, but is abused to do things that it shouldn't, and can cause all sorts of problems. It's definitely not something I want Swift to support.

3. Configuration

This doesn't require message-passing. In fact, the only language support one might want is a way to easily build a table that maps from variable name to getter/setter closure, although doing it in a type-safe fashion seems relatively problematic (the trivial solution is to use Any in the setter closure and fail if the input value is the wrong type, and the getter closure would of course just return Any as well). But even that's just a bit of a nice-to-have and relatively esoteric; you can certainly build such a table by hand.

And of course there are better ways to design this once you've actually defined how you expect your configuration to work (this article does not go into detail). One possible suggestion would be something like a JSON blob that defines key/value pairings that a given object should be updated with. This could in fact be implemented as a protocol on configurable objects, something like

    protocol Configurable {
        func configure_with(json: Dictionary<String,JSON>)
    }

where we're assuming there's already a JSON library that has a datatype called JSON that represents the parsed JSON data. The object itself would then be responsible for checking if each of its properties exists in the dictionary and updating with the mapped-to JSON value (and asserting or ignoring if the type is wrong, depending on preference). This would actually be a lot more flexible than converting strings to methods, because it would allow for defining custom keys that do various transformations on the value, or that update multiple properties from one key, etc.

The one language feature that would help here would be support for `deriving`, which is to say, a way to derive the implementation of a protocol on a given type. Haskell and Rust both support this (I would assume other languages do too but that's what I know of off the top of my head). Of course, in Rust, only traits (protocols) known to the compiler can be derived. I am unclear how it works in Haskell. Ideally if Swift were to gain deriving support there would be some way of extending support to your own protocols, but right now it's very unclear how to properly handle metaprogramming in Swift. Regardless, this seems like a post-1.0 feature, and is not necessary for doing configuration.

4. Remote Methods

I am unclear what the author is asking for Swift to support here. Some kind of built-in distributed objects, like NSDistributedObject and the in/out/inout annotations in Cocoa, is a bad idea, as we have learned from NSDistributedObjects. The author's example of mapping IRC commands to actions seems to be completely unrelated to any sort of language support for this. For that example I'd just have e.g. an IRCEndpoint object that I would register closures with to handle various messages, and the closures can do whatever they want.

5. Runtime Metaprogramming

This is a dangerous topic. Runtime metaprogramming can do interesting stuff, but it's also usually considered to be rather hacky, potentially dangerous, and almost always a bad idea. Among Obj-C programmers that I respect, the general opinion is that if your code includes

  #import <objc/anything.h>

then you've done something wrong, with the only exception being using associated objects (and even there, associated objects are typically considered a solution of last resort).

The author provides a link to a youtube video as an example of something cool you can do with runtime metaprogramming. I am not willing to sit through a 49 minute video, but skimming through it suggests that the idea is to have some sort of class that represents a word and autogenerate methods to conjugate the words. I think. In any case, my impression here is that the runtime metaprogramming is actually a poor man's compile-time metaprogramming. Compile-time metaprogramming is very powerful, but also hard to get right. It's something I think Swift needs, but it's also something that will take a while to design correctly, and is definitely a post-1.0 feature. As an example of how this is powerful, Rust provides compile-time metaprogramming via "syntax extensions", which are dylibs compiled from specially-annotated Rust libraries that are loaded directly into the compiler (which is written in Rust) and given full access to the AST. With this functionality, one of the libraries distributed with Rust is libregex, an re2 regular expression library, and this library provides the regex!() syntax extension that compiles the regex at compile-time and generates native code for matching (as opposed to the normal instruction-based virtual machine for runtime-parsed regexes).

---

Turns out I'm out of time. I think I covered basically everything in the article though.

tl;dr: Swift doesn't need message passing.

Isn't it true that some messages are sent dynamically in Swift? (For example, if you are messaging an Obj-C instance)

Why is there any doubt over the meaning of 'binary compatibility'?

So I've actually been doing a lot of thinking about this, because I have a use case that doesn't work as well as in Swift.

You have some problems. The first problem you have, is that static compilation provides so many routes for cross-applicaton optimization that this is one of the major ways that Swift can be faster than its predecessors. For example, if you have this

    func min<T: Comparable>(x: T, y: T) -> T {  //Generic functions
        if x < y {
            return y
        
        return x
    }

    min(3,5)

    min(5.0,2.0)

The compiler has a lot of possibilities. For example it could translate this function very literally, producing the generic min function that you wrote. It could realize that you only use this for floats and ints, and emit 2 particular specializations of the min function. It could specialize the float function and use the generic function for ints, or vice versa. Next, it could inline any of these, none of them, or some of them. Finally it could do three different things depending on if you're x86-64, armv7s, or arm64.

I have no idea what the right thing to do is in this situation, but having all those possibilities gives the compiler a better chance of producing faster code. When you introduce message passing, you basically forbid all of those optimizations, because now the function might be swizzled, go pass a "minX:Y:" string to objcMsgSend to find out what pointer we should jump to today.

Swift already does have a way to opt-in to message passing, it's called the @objc flag (and performSelector:). It works fine, but it's extra work to opt into it and use it. But, I don't think that's bad given that it disables so many useful optimizations.

What may be bad is that the name "@objc" is a dead giveaway that this is a feature with a deprecation date. So I think we need some other, reflectionish system going forward.

For mocks one idea would be to selectively turn on message-passing as the dispatch method at the compiler level. So you could compile your application for unit testing with a "-fmessage-passing" like we have "-fobjc-no-arc" and get all the dynamism in debug builds and turn them off for release builds (or not, as the case may be).

For everyday power programming I think the answer is a lot simpler: functions are first-class objects in Swift, so just take your functions, put them in a dictionary somewhere and implement your own run-time dispatch. Having done this, I can say with certainty that there are some ways the language could improve this use case but it is possible, and if you are Chris Espinosa wrestling a bit with the type system is not a problem.

Things are tricky when you don't have the source code, but here again I see a reflection-ish API as being the key. I expect at some point we will be able to enumerate other classes' public methods, and dynamically dispatch into them, and that is certainly a missing feature with valid use cases.

Finally, I fundamentally and strongly disagree with Michael about method swizzling and OSX extensibility. Adding PGP to Mail via hooking functions sounds like an incredibly deranged idea. The suggestion that programs should cooperate with a badly-misguided reverse engineering effort by disabling optimizations that make the program faster for the other 99% is just insane. The way to approach this is to build new kinds of extensions that provide known, safe, documented extension entrypoints for hooking arbitrary code. Yes that is more work, and yes it requires actually talking with people and convincing them of your point of view, but so do most things.