19 Feb, 2019The Profligacy of Immutability
There have been a couple of times over the past few months where I have run into major performance issues due to excessive garbage collection when trying to create dynamic models that work with immutable data objects used in 3rd-party code. Even just one or two immutable classes in a library can have huge flow-on effects. I have no problems with functional programming and immutability per se, but when that code starts gorging on new memory and leaving behind a trail of garbage for others to clean up, then it's time to register a complaint.
22 Mar, 2013Event Handling in Analysis Classes
As I have mentioned in a couple of other posts, I have been working on the API for a suite of building performance analysis classes, with a particular focus on dynamic visualisation and interactive manipulation. Part of this involves implementing an event notification system so that changes can propagate through even the most complex object hierarchies without the user having to worry about the internal plumbing. Unfortunately the standard approaches that I have found aren't particularly suitable here, so I have had to hack out something of my own.
28 Sep, 2012Where's the Point in 3D APIs
Whilst working on an analysis library recently, I have been trying to reconcile how best to define positional and directional information. Most 3D frameworks and Application Programming Interfaces (API) use a single Vector class (or similar) to define a generic object with X, Y and Z properties, which is then used interchangeably to describe both points in space and direction vectors. The closer I look, however, the more I think that it's important to clearly distinguish between the two and treat them as separate classes in an API in order to avoid inadvertent user mistakes. Unfortunately there is no single knock-out justification for either approach, so the following are some simple contemplations on the subject as I try to work out which way to go.
23 Sep, 2012Designing for Sub-Classing in Java
One of the projects I have been working on over the last few months is a graphical user-interface (GUI) library for Processing. The Java API to the library makes extensive use of sub-classing and the intention is that it be easily sub-classed by the end user to allow for deep customisation of its functionality. Deep customisation means allowing for any property in any of its classes to be easily overridden. Sounds trivial as this is what object-oriented programming and Java is all about, but it actually leads to an interesting code-design dilemma.