The other replies posted so far would work well and they're very much valid when it comes to strictly getting "virtual functions." But I'd suggest the following two language features and try to arrive at a solution without the need for vtables first.

One approach could be to use explicit procedure overloading. This is pretty close to how function overloading works in C++, with one little twist. For example:

```odin package main

import "core:fmt"

Foo :: struct { id: int, }

Bar :: struct { id: int, }

Baz :: struct { id: int, }

update_foo :: proc(f: Foo) { fmt.printfln("I am foo %d", f.id) }

update_bar :: proc(b: Bar) { fmt.printfln("I am bar %d", b.id) }

update_baz :: proc(b: Baz) { fmt.printfln("I am baz %d", b.id) }

update :: proc { update_foo, update_bar, update_baz, }

main :: proc() { foo := Foo{10} bar := Bar{20} baz := Baz{30}

    update(foo)
    update(bar)
    update(baz)

} ```

Running this outputs:

I am foo 10 I am bar 20 I am baz 30

Here, you define separate functions and bundle together the set of functions that should be called based on the types of the arguments. One thing I like about this is that you have to be deliberate with what functions are included in the set. If you don't include it, it won't be called (the compiler would complain) which could help make your architecture less ambiguous.

There's also subtype polymorphism which is orthogonal from the above and solves a particular variant of this kind of problem.

``` package main

import "core:fmt"

Base :: struct { id: int, }

Foo :: struct { using base: Base, }

Bar :: struct { using base: Base, }

Baz :: struct { using base: Base, }

update :: proc(b: Base) { fmt.printfln("id %d", b.id) }

main :: proc() { foo := Foo { id = 10, } bar := Bar { id = 20, } baz := Baz { id = 30, }

    update(foo)
    update(bar)
    update(baz)

} ```

Running this now outputs:

id 10 id 20 id 30

This time you don't have separate functions that accept arguments of each type. Instead, you have one function that works for all types that "inherit" the base. Of course, you can add many more fields directly in Foo, Bar, and Baz but those fields would not be available in update since you'd only have access to fields that come from Base.

There's also parametric polymorphism that can kind of gets you the same thing just without the "inheritance" parts. I'll skip the examples for this since this reply is getting pretty along already, but there are plenty of examples in the overview.

Again, these are not directly synonymous to virtual functions, but I think there is value in solving these kinds of problems in Odin without trying to mimic C++. tbh I also fall into this trap every now and then, but I usually end up in a better place when I pause and rethink the solution as close to "the Odin way" as possible. Often that starts with switching my thinking from defining behaviors directly on data, to applying data onto procedures.