Notes on the Module "Base"

What Does It Do?

This module is a small helper library that has been spun off from the API module, the main library.

This might seem overly complicated, but in fact, it was necessary, because the author uses it in another, external project as well, without using the API there.

What is This Repo's Relationship with the Other Repos?

• This is a module-level repository which is part of a multi-module project, i.e. it has a parent and several siblings.

  Parent

• Under normal circumstances, you cannot compile it on its own (at least not without further preparation), but instead, you should clone it together with the other repos and use the parent repo's build-script.

• This repository contains no history before V. 1.7 (cf. notes in parent repo).

Major Changes

V. 1.6 → 1.7

• Introduced new (dummy) ID types: GCshAcctID, GCshTrxID, etc., all derived from GCshID.

  Rationale: Improve type safety and overall robustness, the really important part being to use those new types in the the interfaces of the other modules, e.g.:

  getAccountByID(GCshID acctID) → getAccountByID(GCshAcctID acctID)

  [ As an aside: This now looks much like the according types and methods in the sister project, but in contrast to there, there is actually no internal difference between those types. ]

  The author has been weighing over the pros and cons of this step for quite a while now (admittedly, it seems exaggerated at first glance) and finally came to the conclusion: Yes, it should be done -- not so much for the symmetry between the two sister projects (one can also over-emphasize that), but for the (pseudo-)type safety and thus in order to significantly reduce the probability of making certain kinds of mistakes (and also to reduce the time finding them), fully leveraging Java's static type safety -- both for the developer(s) of this lib and for its users (after all, that was the rationale behind the introduction of GCshID in the first place, the original author handling e.t. just with strings -- yes, it worked, but it's far too error-prone).

V. 1.5 → 1.6

• GCshID: Added constructor with UUID (this comes naturally).

V. 1.4 → 1.5

• FixedPointNumber: Ironed out some inconsistencies: Some methods would change the (value of the) object itself, some others would not and instead generate a new one. Now, every calc-operation changes the (value of the) object itself.

  This admittedly leads to less-than-beautiful code in the other modules, because you now have to use the method copy() a lot of times, but we had to do so before the changes anyway here and there, and at least it's consistent now.

• Better test coverage: Now, I feel much better about it.

• Finally: Moved package numbers to SchnorxoLib (and thus merged it with the almost 100%-redundant code in the sister project's according package).

V. 1.3 → 1.4

• Created, spun off from the API module.

• Better test coverage

Planned

./.

Known Issues

./.