Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Objective-C Runtime and Swift Dynamism

academy.realm.io

Post reply on HN
Print view View original

11–20 of 41 posts

Re: The Objective-C Runtime and Swift Dynamism

#11

Post by jernfrost »

bogomipz wrote: post #8

>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?

Really just means a dynamic language just like smalltalk, LISP, python, Ruby etc. Like Objective-C all these allow you to add classes and method at runtime.

Re: The Objective-C Runtime and Swift Dynamism

#12

Post by Apocryphon »

jernfrost wrote: post #11
bogomipz wrote: post #8

>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?

Really just means a dynamic language just like smalltalk, LISP, python, Ruby etc. Like Objective-C all these allow you to add classes and method at runtime.

It's interesting that Swift is a static language, despite having the lightweight modern syntax similar to Python or Ruby. Though I suppose Go is the same way.

Re: The Objective-C Runtime and Swift Dynamism

#13

Post by chc »

Apocryphon wrote: post #12
jernfrost wrote: post #11

Earlier quoted context omitted.

Really just means a dynamic language just like smalltalk, LISP, python, Ruby etc. Like Objective-C all these allow you to add classes and method at runtime.

It's interesting that Swift is a static language, despite having the lightweight modern syntax similar to Python or Ruby. Though I suppose Go is the same way.

Haskell is one of the most strictly static languages around, and its syntax is super light weight.

Re: The Objective-C Runtime and Swift Dynamism

#14

Post by thewayfarer »

This is particularly relevant right now. The swift-evolution mailing list is currently discussing adding a "dynamic member lookup" protocol to Swift to enhance interop with dynamic languages like Python, Ruby, and Perl. You can see the proposal here[0].

[0] https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae...

Re: The Objective-C Runtime and Swift Dynamism

#15

Post by [deleted] »

bogomipz wrote: post #8

>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?

[deleted]

Re: The Objective-C Runtime and Swift Dynamism

#16

Post by alkonaut »

chc wrote: post #9
bogomipz wrote: post #8

>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?

I think it means "dynamic," in the sense that when you call a method, the object's class is looked up and the class's method list is looked up and the methods' implementations are looked up and the class is even given a chance to handle the lookup itself. It doesn't just support reflection, it reflects pervasively. This basically corresponds to what we usually mean when we say a "dynamic language."

Is that lookup done all the time (for each invocation of the same method):? Or is it done at a single point in time, like a JIT, but after that the method is “fixed”?

With the possibility to intercept/replace code at runtime (at any time, not just at a resolve/jit stage) it must be very hard for the runtime to optimize calls (i.e make direct calls instead of indirect via method pointer lookup)?

I’m not familiar with how this works in any runtime (V8, Hotspot, ...) so I’m curious which runtimes actually pay one extra method pointer lookup forever and which don’t. I’m guessing the answer for nearly all of them is “it depends”.

Re: The Objective-C Runtime and Swift Dynamism

#17

Post by jonhess »

alkonaut wrote: post #16
chc wrote: post #9

Earlier quoted context omitted.

I think it means "dynamic," in the sense that when you call a method, the object's class is looked up and the class's method list is looked up and the methods' implementations are looked up and the class is even given a chance to handle the lookup itself. It doesn't just support reflection, it reflects pervasively. This basically corresponds to what we usually mean when we say a "dynamic language."

Is that lookup done all the time (for each invocation of the same method):? Or is it done at a single point in time, like a JIT, but after that the method is “fixed”? With the possibility to intercept/replace code at runtime (at any time, not just at a resolve/jit stage) it must be very hard for the runtime to optimize calls (i.e make direct calls instead of indirect via method pointer lookup)? I’m not familiar with…

The lookup happens on each invocation. It’s alway indirect, and the implementation of a method can be changed at runtime. Method calls aren’t optimized to be direct invocations.

Re: The Objective-C Runtime and Swift Dynamism

#18

Post by 0x0 »

alkonaut wrote: post #16
chc wrote: post #9

Earlier quoted context omitted.

I think it means "dynamic," in the sense that when you call a method, the object's class is looked up and the class's method list is looked up and the methods' implementations are looked up and the class is even given a chance to handle the lookup itself. It doesn't just support reflection, it reflects pervasively. This basically corresponds to what we usually mean when we say a "dynamic language."

Is that lookup done all the time (for each invocation of the same method):? Or is it done at a single point in time, like a JIT, but after that the method is “fixed”? With the possibility to intercept/replace code at runtime (at any time, not just at a resolve/jit stage) it must be very hard for the runtime to optimize calls (i.e make direct calls instead of indirect via method pointer lookup)? I’m not familiar with…

There's some good info on that here:

"Dissecting objc_msgSend on ARM64" https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti...

"Let's Build objc_msgSend" https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-bui...

There's also the "Illustrated history of objc_msgSend", although it appears a bit dated, it has some nice commentary on the evolution of this very performance-critical part of the objective-c runtime: http://sealiesoftware.com/msg/index.html

Re: The Objective-C Runtime and Swift Dynamism

#19

Post by bogomipz »

chc wrote: post #9
bogomipz wrote: post #8

>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?

I think it means "dynamic," in the sense that when you call a method, the object's class is looked up and the class's method list is looked up and the methods' implementations are looked up and the class is even given a chance to handle the lookup itself. It doesn't just support reflection, it reflects pervasively. This basically corresponds to what we usually mean when we say a "dynamic language."

So more or less dynamic dispatch then?

Re: The Objective-C Runtime and Swift Dynamism

#20

Post by panic »

bogomipz wrote: post #8

>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?

The usual name for this is "late binding". It became popular because of Smalltalk, and it's a core principle of the "pure OOP" languages (like Self, Obj-C and Ruby) that Smalltalk inspired.
Post reply on HN