I meant the following: transitioning a project using current methods to using methods with vtables may not be an easy thing to do, as there is the limitation of having to declare the methods in the same type module.
In my case, a project where I have a lot of method calls, I wanted to test the performance of the new vtables, it is not an easy modification to make, as it will result in several cyclical imports if I simply throw the types into the methods module or vice versa. Furthermore, there is a lot of interrelationship between the types...
So, the question is: would it be possible to remove the vtables limitation of having to declare the method in the same module as the type?
would it be possible to remove the vtables limitation of having to declare the method in the same module as the type
Like the former implementation, the vtable implementation generates dispatchers only in the main module codegen in order to collect all the possible method defintions among modules. You cannot generate vtables for that module when you cannot predict where users will define their methods. Developpers are free to define methods for types in another module, but TNimTypeV2 has to be generated for the module where types are defined. It cannot be initialized with vtable arrays if the knowlege hasn't been learnt, but it has to initialize regardless because it can be used in that module.
transitioning a project using current methods to using methods with vtables may not be an easy thing to do, as there is the limitation of having to declare the methods in the same type module.
I suppose It's much easier to implement experimental:vtable per module with some overhead than to drop the limitation.
How to handle cycles: Lie (a little) about the type:
type
Foo = ref object
barImpl*: RootRef # Bar
Other module:
type
Bar = ref object of RootObj
f: Foo
template bar(f: Foo): Bar = Bar(f.barImpl)
Notice how Bar already usesd inheritance previously, how else would you be able to use method for it?
What is the advantage to have the C++ vtable implementation?
Better performance and it supports the IC mechanism without requiring (pre-)link-time code generation.