12 Mar, 2019The Wonders of Duck Typing
Having immersed myself entirely in JavaScript for the past few years, going back to something like C# should have been a bit of relief. However, it mainly served to highlight just how inflexible and full of unnecessary overhead C# is, and just how much I love the flexibility and interoperability of JavaScript. This particular post details one of those ridiculous situations that languages like C# often create, with a relatively simple app containing at least 6 different classes/structures for storing 3D position data, many of them pretty much the same but entirely incompatible with each other.
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.