[jeswin]

> Traditional OOP runtimes use vtables for method resolution, adding a layer of indirection on every call. Perry resolves all method calls statically during compilation, turning interface method calls into direct jumps.

What? How is this possible, even with something as simple as:

  interface Animal {
    speak(): string;
  }
  
  class Cat implements Animal {}  
  class Dog implements Animal {}

  function makeSound(animal: Animal) {
    return animal.speak();
  }

[ventana]

I only grepped "vtable" in the repository so this might be not the relevant piece of code, but from the comment in [1] it seems they fallback to building a vtable if the static resolution is impossible.

[1]: https://github.com/PerryTS/perry/blob/39d5ba2e9db5adf7f7fc90...

[fooker]

You can just generate the 'vtable' as code :)

  switch (animal.type)
    case Cat: return cat_speak()
    case Dog: return dog_speak()

The generated code has the functions resolved in compile time, there's no function pointer lookup in a table happening. I don't know if this is how this project does it, but this is the commonly used technique when you want to do this.

[jeswin]

Hmm yeah good point. I didn't think of it. It might even be cheaper to do this when the list of possible types are closed and few.

I am still inclined to believe AI just made up the documentation though, because this has its own tradeoffs.

[fooker]

> might even be cheaper to do this

Oh yeah, very often. Especially if it's a loop and resolves the same way very often.

Modern CPUs just blaze through code like this, after three decades optimizing for object oriented and dynamic languages.

[avaer]

It's not possible, it reduces to the halting problem, unless you start restricting the Javascript/Typescript you allow.

Otherwise the best you can do is be solid on common special cases. Which is what a modern (non-static) JS/TS runtime is.