Reading the code for specification information is terrible. First and foremost, you have licensing issues if developers have to read the code and write their own code based on it. There's a reason clean-room reverse-engineering efforts go to great lengths to avoid reading anything that can be construed as source code for the thing they're reimplementing, utilizing either middle-men who can read the code and write their own interpretation of the public behavior, that the developers then read to implement from scratch (ensuring they never see any source code and are just replicating behavior), or by black-box testing, with the developers writing their own test programs using the public interfaces with various inputs and checking the results, and write their own implementation that behaves the same. Even if you don't directly copy the code, when you're known to have used or had access to it, the onus is on you to prove it's not been copied (in a legal sense) if you don't want to inherit its license. Some companies disallow their employees from looking at code with unacceptable licenses, even if they have no intention of copying it. And according to the Doom Wiki, the code is GPL, which not everyone will want to or can be bound by.The good thing is that anyone can already incorporate ID24 technology since its an open spec. Don't let the author of said spec cloud your judgement and just look at the code instead, with the warning that it is non-final.
Secondly, reading the code doesn't distinguish between public specifications and internal implementation details. There's no reliable way to distinguish between a bug in the code and intended specification behavior (if there's a signed type that doesn't check for negative, are negative values intended to be supported?). Or when there is an apparent code bug, what the fix should be from a specification perspective (e.g. if there's an integer overflow in the code, is the fix to use a wider integer type to avoid overflow? or restrict the maximum to the largest value that won't overflow? or restrict it to some other "reasonable" lower value?).
Thirdly, isn't it a problem for this to be "non-final"? Being an open spec is great and all, but if things aren't final and are subject to change, what good is it to implement something (let alone create mods using it) if the next day it gets changed in a way that much or most of the work has to be redone from scratch while breaking existing mods relying on the old spec? There has to be a list of things set in stone that can't and won't change. At least until that happens, it's rather pointless for others to implement or use for production purposes.
Statistics: Posted by Chris — Mon Sep 09, 2024 12:30 am