[Kde-hardware-devel] bool longMode() function. Too restricted?

[Rick Stockton]

On 04/20/2011 02:07 PM, David Hubner wrote:
> I am looking to create a patch that would add a new public member to
> show if a processor was 32bit or 64bit.... I [am]
> thinking [of] calling the public member bool longMode();
David, I'm unqualified to comment about this, but I'd like to bring this 
thought of an "amateur" to your attention. (After which, YOUR choice 
rules ::))

I think the boolean return value is too limiting. The x86-64 companies 
are almost certain to extend the current capabilities in the future. And 
at that point, it looks to me like you will need to add ANOTHER new 
function to distinguish "longMode" == bool(true) from "x86-100", or 
"x86-128", or "x86-fancier-VM-control-registers" or whatever. (New 
functions at a future time,  because we started from an API Signature 
which couldn't handle multiple values.

I recommend integers values, because they would offer KDE Coders a key 
advantage over strings: They would be able to write "greater than" and 
"less than" comparisons to cover several possible values at once. With 
Strings, they might need more coding to handle the code implementation 
"decision tree" which the return value leads them to step into. ENUMs 
also have less flexibility, but if you choose to use an ENUM, be 
absolutely sure to reserve lots of unused space for future values. 
(Please, not less than 32 possible values.)

Why do I feel strongly about widened ENUMs? Well, I've taken on the 
ancient KDE "Why don't we see ALL the mouse buttons on X11" problem, and 
the way-too-small ENUM used there (a single byte) has created a 
basically unsolvable Endian problem. (It doesn't matter how large the 
machine Registers are when the alignment of the "added" bytes won't 
match.) I'll have to do the higher-numbered buttons with a separate API, 
which creates more coding and confusion for programmers now, and also 
adds obsolescence hassles when QT5 and KDE5 get going.