the two-vtable problem

posted on 2021-11-21

when programming, there are in general two types of interfaces: "static, known" interfaces and "dynamic, unknown" interfaces.

in the former, the possibilities are well known. maybe an object has a bunch of public methods that can be used, or maybe even public fields; maybe an API has a known call endpoints.

when the behavior or contents of an object are unknown or inaccessible, someone can still implement how it interacts with another known-interface object: just send the known object to the unknown object, and let the unknown object manipulate the known object however it wants.

however, there is no general way to make two (or more) objects interact with each other, when they both have a dynamic/unknown interface.

this is what i call the two-vtable problem.

one approach is to implement all n² behaviors: implement the behavior for any possible concrete type of one object and any possible concrete type of the other. the rust ecosystem is kind of like that with types and traits: if you have N types and K traits, unless one of those traits has a blanket implementation for all types, you'll need to write N×K implementations to have proper coverage in the general case.

but this is hardly scalable; and doesn't work well, for example, in environments in which objects are expected to be implemented by different parties that don't necessarily coordinate with one another, where those objects are then expected to work together without putting in extra effort afterwards. i'm sure this probly has been encountered a lot for example in video game modding communities, regarding the interaction between mods created by different people.

an answer can be taken from other fields that have already solved that problem on their own, however. i can think of two: how natural selection solved negotiation between dynamic persons, and how liberalism solved negotiation between dynamic private actors.

the general solution to the two-vtable is to have the two objects have a language —as tells us the evolution of humans— that they can use to communicate and negotiate an outcome. liberalism tells us that the shape of negotiated outcomes is contracts, and cryptocurrencies tell us that the formalized form of contracts is programs.

and so, here is my proposed solution to the two-vtable problem: when two dynamic objects want to interact with one another, that interaction must take the shape of the two of them building a program together, which will be executed once they both agree on it. perhaps this can take the shape of both of them sending an initial contract to the other which is ideal from the perspective of the sender, and from there try to incrementally build up programs that implement a compromise between the two ideals, until they meet somewhere in the middle; like haggling.

this framework generalizes nicely enough that it could be used for arbitrary informatic agents, such as a bot and an uploaded person, or two uploaded persons. in fact, contract negotiation of that kind, when understood enough by both agents partaking of it, can be the formalized form of consent, a matter i've grappled with formalizing for my utopia.

this could also be useful for negotiation between different compilation stacks for portable programs, or even for the negotiation between different wasms running on a liberal server market.

posted on 2021-11-21