PCGen Libraries

On Why they exist

There are two major reasons the new formlua system was put in a library:

1. None of it needs to be PCGen-specific, and the separate library forces that more gereric design thinking
2. Eliminate the complexity of having JJTree/JavaCC within the primary code base. The jjtree/javacc calls required to build .java files make a more complex build cycle (the challenge being that you have to do a build, then actually select the project and cause it to refresh in order for it to correctly compile the java files to the current version). The number of times we used to require a form of refresh to the project after a JavaCC compile occurred was confusing a large portion of our population of code/data folks that build their own version of PCGen. We therefore extracted that complexity out so that only the code team working on the formula system will experience any of that.

Note that this had the effect of breaking a reasonable portion of the pcgen.base.* also into a separate (and different) sub-project since they are shared dependencies of the core and the formula parser. Since these items are reasonably stable (most have had no more than cosmetic changes in years), it is also a reasonable separation.

On the Library Contents

Early PCGen used almost fully reference semantic lists for storing information. This produced a number of really bad headaches, because folks felt the lists could be modified at any time and the calculations could come out correct. This was patently false, but it didn't prevent it from happening widely across the code base.

Much of the work in 5.8/5.10/5.12 was a very "hard" change to a value-semantic infrastructure. This means any list returned by CDOMObject and its descendents is simply a snapshot of the values at that time - the list was copied and ownership of the list was transferred to the caller to do with it whatever they want.

The reason I bring this up is I frequently get comments on the contents of PCGen-base and "you should go use Google Collections" or whatever. I appreciate the comments, but (a) maintaining these items is not where I'm spending my time (b) it's not where are problems are and (c) the semantics of those classes are almost universally reference semantics, so they are very different to use in an object-oriented system that expects to maintain appropriate behavior and isolation (and difficult to use less experienced developers who don't actually understand semantic differences).

In short, when our system is smaller, and we have the legacy systems removed so that we have a code base in the hundreds of classes (so folks can understand it much easier), then I think that is a viable and valuable discussion to have about the code base. Until then, I think the semantics of PCGen-base are required.