Talk:CHARACTER TYPE NONE
TYPE_NONE != TYPE_A ?
This is just a stupid question. I've been sort of going through a long list of LSL constant values, compiled from different sources, possibly at different times. It seems that, at some point, there were four types A-D, numbered from 0 to 3, and an additional "none" type, which was also set to 0.
But now what seems to be the case is that CHARACTER_TYPE_NONE is set to a new value, namely, 4. This would make adding new types a bit complicated (and probably require many scripts to be compiled otherwise). Wouldn't it make more sense to consider CHARACTER_TYPE_NONE to be "type zero", so to speak, while the other types would start being numbered from 1 upwards?
Granted, this might be encoded in binary, e.g.:
| Description | None? | 2 significant bits | Decimal |
|---|---|---|---|
| CHARACTER_TYPE_A | 0 | 00 | 0 |
| CHARACTER_TYPE_B | 0 | 01 | 1 |
| CHARACTER_TYPE_C | 0 | 10 | 2 |
| CHARACTER_TYPE_D | 0 | 11 | 3 |
| CHARACTER_TYPE_NONE | 1 | 00 | 4 |
Seen that way, it almost makes sense :-)
So, whenever LL adds new types in the future, they just need bump the number of significant bits from 2 to 3. The 'flag' bit for 'none' would still remain in the first bit position, of course, but CHARACTER_TYPE_NONE would become 8 instead:
| Description | None? | 3 significant bits | Decimal |
|---|---|---|---|
| CHARACTER_TYPE_A | 0 | 000[1] | 0 |
| CHARACTER_TYPE_B | 0 | 001 | 1 |
| CHARACTER_TYPE_C | 0 | 010 | 2 |
| CHARACTER_TYPE_D | 0 | 011 | 3 |
| CHARACTER_TYPE_E | 0 | 100[2] | 4 |
| CHARACTER_TYPE_F | 0 | 101 | 5 |
| CHARACTER_TYPE_G | 0 | 110 | 6 |
| CHARACTER_TYPE_H | 0 | 111 | 7 |
| CHARACTER_TYPE_NONE | 1 | 000[3] | 8 |
See? The integer values for A-D would remain exactly the same, E-H would immediately follow D sequentially, but CHARACTER_TYPE_NONE would now be binary 1000, i.e., decimal 8. This would mean that most old code would continue to work, so long as the test for CHARACTER_TYPE_NONE is made in binary — always testing the first bit. 'Old' code would just need to be left-padded with zeros, except for CHARACTER_TYPE_NONE.
A bit complicated for my taste, though!
— Gwyneth Llewelyn (talk) 12:17, 16 February 2024 (PST)
P.S.: Editing wikitables sucks...
- ↑ Bold indicates previous two significant bits, now left-padded with a zero; that way, everything fits neatly together!
- ↑ This would not conflict with 'old' code for CHARACTER_TYPE_NONE, because the 'new' code would check for the first bit on a 4-bit code, and get a zero, so CHARACTER_TYPE_E would be the first of the new types, but, sequentially, it would be numbered 4, without conflicts.
- ↑ In fact, all those bits can be anything, under the assumption that only the most-significant bit matters to determine CHARACTER_TYPE_NONE. This provides a smooth migration path for old code — either it's NONE, and the first bit is set; or the first bit is zero, and the remaining bits determine the type, numbered sequentially, starting with A set to 0.