[Buckleyisms]

From the linked Wikipedia article on Dynamic Dispatch:

> C++ compilers typically implement dynamic dispatch with a data structure called a virtual table that defines the message to method mapping for a given class (C++ as such has no notion of a vtable).

In my article, I'm specifically talking about message passing as implemented in Objective-C and Smalltalk. http://en.wikipedia.org/wiki/Message_passing

Both the term "dynamic dispatch" and the term "message passing" are overloaded, but I used the term "message passing" to differentiate it from vtable dispatch, which I talk about in the article.

I'm not criticizing Swift for being a statically-typed language. I'm only criticizing the way it calls methods.

[hamstergene]

You may not realize it, but it looks to me you are. The points you criticize Swift for are distinctive features of dynamic languages, e.g. to be able to:

* substitute object type without recreating the object

* substitute object's method without changing object's type

* create a string with method name and call that method

Obj-C and most dynamic languages have them; Swift and languages like C++ do not. (I understand that with full reflection and enough runtime hacking static languages can have that too — by the way, that includes Swift as it currently is; but that's a whole different discussion).

In other words: if the compiler has statically (at compile time) validated types of arguments and return values of any `obj.foo(arg)` call, why would anyone possibly want anything but either a direct call to a hardcoded address, or to a pointer stored at vtable? And if the compiler has no means to validate that, that means you are down to what dynamic languages do: there has to be some code to check argument types before passing them to the code that makes hard assumptions about their types.

[Glide]

Your definition were clear from people coming from an Objective-C background and after understanding where Swift is coming from after the WWDC talks.

But you do realize that the way is calls methods is exactly what makes Swift... well Swift.

I sympathize though. Swift feels like it's several yards forward when compared to Objective-C when looking at syntax and language features. It's a couple steps back when looking at runtime hackery (and "power" I guess). Basically something like Core Data is impossible in Swift.

[coldtea]

>Basically something like Core Data is impossible in Swift

Huh? Is it not already available for Swift actually?

Or the problem lies in re-implementing it in Swift?

[Glide]

The latter because of the runtime magic that it uses in NSManagedObject. Watching the WWDC 2014 talk states that the Swift team added @NSManaged so that it's possible to define models in Swift to be used in Core Data.

I also tried wiring up something really quickly in Typhoon (objc-ioc container) and it didn't work with a Swift class. I did do @objc on the class. Something about how properties are defined in Swift. It's pretty much expected because the runtime system is different.

Don't get me wrong, I'm not going to go "omg everything needs to be rewritten in swift!!!" but after trying a toy project or two in Swift, dealing with all of the implicitly unwrapped optionals from objective c code gets a wee tedious. It's a strange feeling. Like all the swift code is safe and the objc code is dangerous somehow. I can quickly see why people would want everything to be done in Swift.