Open Ernegien opened 9 years ago
It seems like most of that page is talking about what we'd already planned, creating a new interface when we're adding new functions and giving plugins a way to use the latest interface version with a typedef (seeing as plugin devs shouldn't really have to worry about interface versions and should just be able to use the latest), I added in the typedef (+ a define that refers to the latest version) in 57bb54b4bf03330d79757099eb90d86510863712
Although they seem to take a step further by also creating new versions of the class as well as the interface, I'm not really sure if we'd need to do that unless there were some drastic changes seeing as the new functions in the class should get mapped to the vftable of the new interface, and the vftables of each interface would be put one after another in the classes actual vftable (ie latest version would be at the end, at least it has from what I've seen), letting us just cast the class between each interface version. Maybe we'll have to do some further testing to make sure these interface vftables are being placed properly though.
Also while the way we do this is weird, I mostly copied this style of interfaces and the CreateInterface function from Valve, eg. see https://developer.valvesoftware.com/wiki/IGameConsole The Steamworks SDK also uses the same interfaces system, and I haven't really seen many problems coming from it.
Yeah, typedefs alone help greatly with readability. As long as we're waterfalling changes to separate versioned interfaces we should be able to somewhat depend on vftable ordering (CTRL+F to "figure 3" in the article), although it appears to be borderline undefined behavior and subject to change. I obviously trust Valve's choices over my limited knowledge on the subject however :)
Refer to the following article to restructure the interfaces for better usability and expansion. CTRL+F to "Finishing polish" for the good stuff. Any thoughts/concerns?
http://accu.org/index.php/journals/1718