[Lazarus] TMask revisited

[Bart]

On Sat, Oct 23, 2021 at 12:02 PM Bart <bartjunk64 at gmail.com> wrote:

> since we are still looking for a better (?) name for the
> eMaskOpcodeOptionalChar enum:

This brings me to another point, and please, please, please don't see
this as criticism of feel offended by me.

Naming conventions.
Typically we don't have the habit of haveing the literal phrase "enum"
in our enum typenames.
We also tend to adopt that enum names are derived form the typename in
a manner like
typename: TSomeType
enum name: stXXX

Then we have TMaskOpcode and TMaskOpcodesEnum types.
The first one is more or less an internal type.
The latter one is for common user interface.
Since TMaskOpCode is used in the interface part of TMask, we must have
it in the interface part of the unit.

If we rename TMaskOpCode to TInternalMaskOpCode and rename
TMaskOpcodesEnum to TMaskOpcodesEnum to TMaskOpcode and
TMaskOpcodesSet to TMaskOpcodes (we tend to do that with sets of
enums: set typename = typename+s), then the opcode enum names can be
changed to moAnyChar, moAnyCharOrNone etc.
So:
TInternalMaskOpcode (integers)
TMaskOpcode (the enums)
TMaskOpcodes: set of TMaskOpcode
Enum names: moXXX

This would be more in line with our unwritten style guide (at least
this is how I percieve it).
Also we have shorter, yet not less intuitive, enum names.

The same for TWindowsQuirks:
TWindowsQuirks: enums
TWindowsQuirks: set of TWindowsQuirks
Enum names: wqXXX

Yes, those are intrusive changes, and they add no functionality, nor
do they fix any bugs, but this is the time to consider such a change.
The new and improved (yes, improved) TMask with all new types won't be
used very much ATM.
In a few weeks or months this might not be the case anymore.

Opinions please!

-- 
Bart