Is type also object in Swift? and what's the meaning of sending a message to an object

Question

This might no be particularity a language related question. Since the Swift is the language I'm currently learning so I'm using it here.

I picked up this sentence from the Matt Neuburg's book iOS 10 Programming fundamentals with Swift

In Swift, "everything is an object" and an object

Object is something you can send a message to.

Let's add an example. Suppose there is a customer type called Dog. It has bark() and sit() function. Two instances of the type Dog named fido and rover had been initiated.

In swift, the syntax of message-sending is dot-notating, like

fido.bark()
rover.sit()
rover.printName()

The above code lines means sending message to object fido and rover

Question 1:

Why the description is: Sending message to object fido and rover? To me it looks like the object fido and rover sends out some message to print it out in the console (ex. printName() ) rather we sending message to it. .bark() looks like it will make fido to do something and shoot its reaction to the outer world, because bark() is the function inside its belly, not something we created and inject in to its body. we just inform this function its the time to work. Is this informing object to do a specific thing is the meaning of sending the message to the object?

Question 2:

"In Swift, everything is an object", an object is something you can send message to 

If I understand correctly, even the object type itself is also an object. such as String, Int or Double. Because type has type properties which means you could send a message to it

Thanks a lot for your time

Answer 1

There is some debate within the OOP world about "message passing" versus "method calling," both in how we talk about them, and how they're implemented. In the prototypical OOP language (SmallTalk, which ObjC is a descendent of), everything really is a "message." I bundle up a message (which is a real data structure, NSInvocation in its most heavyweight form in Cocoa), and deliver it to the object's inbox, which then processes the message and performs some action.

Most common OOP languages didn't adapt this model (when something does today, we tend to call it "actor" rather than "object"). C++, which heavily inspired most of the current crop of "object-oriented" languages took a "method calling" approach. This is much more closely aligned with function calling, and has to do with jumping to a specific point in memory and executing instructions there. Method calling is more static than message passing. It is much easier at runtime to completely reconfigure how messages are handled, create new message handlers, re-route old message handlers, etc. Method calling is much faster.

In practice, there isn't a huge difference in most programs at most call sites. The vast majority of ObjC "messages" translate precisely 1:1 into a method call, and the system almost always avoids generating a full NSInvocation message (they're insanely expensive).

But we still conceptually mix the two ideas when we teach OOP, and that's what's happening here. (Swift also happens to employ both mechanisms heavily.)

A good way to think of fido.bark() is "send the bark message, with no parameters to fido." It is then up to Fido to decide what to do about that. In practice, messages are usually understood to be "commands" in that the object doesn't "decide" what to do. But in principle it might. For example, Fido might be a pretty smart dog, and decide not to bark because it's so late at night, even though you told him to, or maybe he's asleep and he doesn't like to bark then. The concept of objects is that they encapsulate that knowledge and state.

To your second question, in Swift types are not full objects. They're "metaobjects." You are absolutely right that you can send messages to them, and so they in some ways behave like objects. But Swift doesn't have "first class types," which means that not everything you can do with an object can be done with a type. But yes, you're definitely on the right road that in many cases you can treat a type as if it were an object.

(A major Swift feature request is to make types more first-class by adding a concept called Higher Kinded types. This would make it possible to write methods on Array itself, rather than only on Array<T>, and make some types, like Functor, possible to write at all.)