UnitParser code >
Since I firstly thought about building a unit-parsing library, my intention was relying on one class (or, at least, on a very limited number of them). Apparently, such an approach wasn't evident to everyone. Note that I have a relevant industrial-engineering background (i.e., BEng in Industrial/Mechanical Engineering, studied for my MS in Industrial Engineering and had some closely-related working experience), the field of expertise which precisely includes metrology. This is perhaps the reason why my expectations regarding the performance of such a tool were notably different to the ones of other programmers.

Logically, the used coding approach cannot constrain the reliability and usability of the generated piece of software. By bearing in mind that unit parsing (understood in its widest sense by also including conversions, operations, classifications, etc.) is intrinsically associated with multiple not-modifiable-by-the-user scenarios (e.g., incompatibilities between unit types), the immediate consequence of ignoring a multi-class approach is having to systematically rely on readonly fields.

Additionally, there is another issue which justifies the importance of instantiation in the UnitParser code: its most distinctive feature (i.e., parsing unit information contained in string variables) is precisely triggered at class instantiation.

The folder Constructors includes the main code associated with the UnitP constructors and contains the following files:By definition, assigning values to the readonly fields have to be performed in the aforementioned constructors. These fields define the pure essence of each UnitP variable. Roughly speaking, they allow one single class to behave as an infinite number of them, via creating unmodifiable rules exclusively affecting a given subset of elements. Each UnitP instance is defined according to the following readonly fields: