If Your Only Tool Is a Hammer Then Everything Looks Like a Nail

While I was working on the project in the past week a few things of note came up that are worthy of mention. At great time-expense, a mentor was gracious enough to do a thorough code-review. The review fished out a lot of unaddressed problems lurking within the code, chief amongst which was the apparent sparseness of the various set and get methods inside the library. For the get methods I was neglecting to throw a PropertyUndefinedError [ I was unaware that such errors could be thrown in the place of primitives, go figure ] on the event that the requested entity is nonexistent and no NullPointerException should be thrown. Similarly, all the set methods were missing the proper listener notifications. While I had done this for a few of the set methods, the importance of it all had been somewhat lost on me. It is only when I did my own modest investigations and became privy to the internal workings of the library that the gravity of the task crystallized in my mind and I set about implementing the required modifications.

The presence of these problems in the first place is perhaps best explained by the title of this entry. This far into the project, the current ASTNode class, has been my primary reference. All the features I have implemented have been informed by whatever implementation is currently present in the ASTNode class. Thus, it never occurred to me to question any of the code I was mimicking (especially when the code's purpose was unclear, as is generally the case given how monolithic ASTNode is). This whole ordeal, has just reminded me of the importance of always being skeptical and keeping an open mind when examining other people's code.

There were also a few issues with inconsistency, misleading javadocs and innocuous problems of a similar quality (i.e. not a pressing issue, but still worth looking at). With the help of my mentors I compiled a list of all the major problems plaguing the app and sought to address them over the latter half of the week. I believe that I have been largely successful. As the new week commences there's only a few ends I need to tie up. The new features that I've added include, (1) Adding a proper clone method to each class. (2) Adding proper constructors to every class. (3) Using Eclipse to automatically generate class-specific toString() methods that implement string builders (4) Lay the framework for a new compiler ... etc

Another issue that was raised that as of right now remains unaddressed, is the issue of which classes to keep abstract. After a code review led by one of the mentors it came to our collective attention that the ASTNumber and ASTFunction classes really didn't have to be regular classes, since what they (both) represent is somewhat generalized and amorphous. During regular use of the library it is unlikely that users will find any need to create instances of either class directly, thus making their constructors unnecessary.

Finally, duplication within the class hierarchy, as exemplified by the ASTCSymbol group of nodes, has been a contentious area, with more than one person citing unnecessary duplication and calling for a better way of representing the implied relationships. As with the ASTNumber / ASTFunction the final solution will have to be a collective decision. This is why I have been hesitant in implementing a solution (even a tentative one).

The next non-JSBML entry I post will focus on Eclipse. Eclipse is powerful, and is pretty much the IDE of choice for Java developers. Eclipse's popularity is due. in large part, to its impressive and easily tractable plugin system (implemented with OSGi) as well it's large store of features, many of which, are directed towards enhancing productivity for power users. These so-called 'productivity-boosters' will be the main focus of the next entry. Hopefully, they will be able to spur some sort of discussion on the topic.

And so it begins ...

Many things of note happened last week. For one, there was a meeting on Wednesday where I was given a chance to present my findings to the JSBML team. The meeting allowed me to get even more feedback on the math package's design, which was good. Until then, the scope of my inquiries had been somewhat limited. While the simulation core library is perhaps the most important use-case to consider at the moment, there are still numerous JSBML-dependent applications / libraries out there that need to be examined scrupulously. So in addition to being an important evaluation tool - both for the mentors and myself - the meeting enabled me to perfect the design and gain some measure of perspective. With so much at stake, it is sometimes difficult to grasp the full implications of every little change made to the design. Luckily, my mentors and GSoC peers have been incredibly helpful and patient. If it was not for their guidance and constructive criticism, the design would not have progressed to it's current state, so for that, I would like to offer my sincere gratitude.

Overall, not much of the design changed over the course of the meeting. It did come to our attention that two of the projects being presented had mutual overlap and that this might be a cause for concern (i.e. conflicts might emerge). Specifically, the worry was that the current class hierarchy might not fit with what was being planned for the arrays package (or vice versa). As far as I can tell, this is not an issue any more. As long as the features of the new ASTNodes are in line with the features proposed in the hierarchy, there shouldn't be any trouble integrating them into the final design.

Now that the minute details of the design have been agreed upon and finalized, I have started writing the code for the math package. The overall structure of the package is self evident, so there was not much difficulty in setting that up. All the relevant classes are included in the new math package. Similarly, all the relevant MathML attributes have been placed in the appropriate locations. Most of the expected ASTNode features have not been transferred over to the new ASTNode, yet. Hopefully I will be able to accomplish this over this week.

In retrospect, the timeline that I'd constructed initially seems woefully inaccurate. Now that I have actually started with the actual coding, I am starting to see just how much my hands are tied. There's not much lattitude, with how you could approach this issue. Development has to be strictly top-down, otherwise it won't work. Both the ASTNumber and ASTFunction classes cannot be completed (fully) unless the ASTNode2 class is complete. The same observation holds when you examine the rest of the classes. Therefore, having a free-for-all, cherry-picking strategy, like I had in my original timeline, seems remarkably naive in retrospect.

Over the past week, I've also been researching bitwise operators. I've been doing this more out of curiosity than any real motivation to implement them in JSBML. To that end, I've only progressed to the point where I know, generally, all the different kinds of bitwise operators and bit shifts and what they do. As far as translating them into something tangible, I am still at an impasse. I will offer something more substantive on bitwise operators and bit shifts later on (benchmarking too). For now I will just leave this here.