About varocarbas.com

--

About me

--

Contact me

--

Visit customsolvers.com, another side of my work

--

Valid markup

--

Valid CSS

--

© 2015-2017 Alvaro Carballo Garcia

--

URL friendly

--

Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode

PDFs:

Project 10

Project 9

Project 8

FlexibleParser code analysis:

UnitParser

NumberParser

Tools:

Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2

(
)

FlexibleParser raw data:

Unit conversion (UnitParser)

Compound types (UnitParser)

Timezones (DateParser)

Currently active or soon to be updated:

Domain ranking

FlexibleParser (DateParser)

NO NEW PROJECTS:
Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
Completed (24 days)
Completed (57 days)
Completed (26 days)
Completed (47 days)
Completed (19 days)
Completed (14 days)

Introduction >

UnitParser Code (.NET/C#) >

Instantiation

DateParser Code (.NET/C#) >

FlexibleParser
UnitParser code (.NET/C#) >
Instantiation
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:
  • Unit (Units enum). Best named-unit match under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit-defining fields.
  • UnitType (UnitTypes enum). Unit type under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit-defining fields.
  • UnitSystem (UnitSystems enum). Unit system associated with the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit-defining fields.
  • UnitPrefix (Prefix variable). Unit prefix under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit- and value-defining fields.
  • UnitParts (UnitPart list). Unit constituent parts under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit-defining fields.
  • UnitString (string variable). Unit string representation under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit-defining fields.
  • ValueAndUnitString (string variable). Value and unit string representation under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other unit- and value-defining fields.
  • BaseTenExponent (int variable). Base-ten exponent under the given conditions.
    It has to be readonly to ensure a perfect synchronisation with all the other value-defining fields.
  • Error (ErrorInfo variable). All the error and exception information associated with the current conditions.
    It has to be readonly to ensure a proper error and exception definition.