The first day of Devember is now over, with some porting effort complete, some mild mystification of how TypeScript operates, and a couple of niggles regarding the used tools.

First things first; the repository for the code of this project is being hosted at: https://gitlab.com/OdatNurd/devember-2015/commits/master.

I’m using just a single master branch (for now, at least), but I will commit any code generated at the end of each day, and tag the final commit of the day. I figure this is a good way to track exactly how much was done on each day. Day one’s commits have been pushed up for perusal by the masses.

So, how did the first day go?

I started the development effort by perusing the online TypeScript handbook to learn a little about the language. I didn’t delve overly deeply here, but I did verify that the syntax is sort of a mash-up of JavaScript and Java with a kind of bizarre type specification system.

I should also point out that I’m using WebStorm as my IDE (for good or for ill; I like to think that it’s a 50-50 kind of thing) for this operation, since I tend to use it for JavaScript development as well. I’m a little bit of a masochist when it comes to languages like Java and JavaScript for weird esoteric reasons.

In any case, I spent a little bit of time getting WebStorm set up to compile TypeScript by way of a configuration file that tells it exactly what files to compile and then commenced with the porting effort. In the first day I managed to get my Point, Actor, Entity and Scene classes done, as well as a part of the Stage class.

Overall, so far I’m pleased with the level of cruft that TypeScript imposes on your code; it’s definitely miles ahead of having to manually fiddle with prototypes in JavaScript. It was very easy to fall into the new language syntax and get things rolling.

WebStorm is kind of annoying

It didn’t take very long to run into some bugs in the TypeScript support, most notably the code formatting options. There are some latent bugs that crept into WebStorm 11 when it was (in my opinion) rushed out the door at the start of last month as part of the new JetBrains subscription service. These bugs manifest in JavaScript and also carry across to TypeScript. Most of my problems with JetBrains tools involves working around its spotty code formatting, so this was not entirely unexpected.

TypeScript and cyclic depedencies

The only other major hurdle of note has to do with circular class dependencies. I was originally setting up all classes in a nurdz.game namespace, but I ran into problems with dependencies between classes. I had to do a little bit more research, but it appears that the appropriate solution is to use something called an internal module.

This seems to be a take on a namespace in which you have to explicitly point out what members of the module are meant to be seen by other modules. I found this kind of confusing because I would have assumed that a namespace would implicitly be a structure that you expect to contain public code; this is however not the case.

In practice the TypeScript compiler seems to only remember things that it’s seen in other namespaces if that namespace is a module that has items exported from it. I’m not sure why that’s not just a matter for the public/private modifiers that the language seems to support, but hey, it’s only day one here.

Going forward

On the whole I would say that things are going well so far. The only thing that has currently given me pause and is something that I will have to ruminate on before I start development tomorrow has to do with how my entity class expects to have properties that define how it operates at runtime.

In the JavaScript version of the code, I have this set up to just be a plain JavaScript object. Entity subclasses inherit a default set of properties from their parent classes and can apply their own. Each subclass is responsible for validating the properties that it added or expects to find.

In the TypeScript version it seems like the best way to go about this is to use the TypeScript structural type system and interfaces, which appears to operate very similarly to a C/C++ typedef type of situation; you can create an interface and indicate what properties conforming objects should have (including making them optional) which allows the compiler to ensure that object values have properties at compile time.

This seems like a good idea; create a base interface named EntityProperties that includes the base entity properties, and then have subclasses of entity extend this interface. I think this would remove the need to validate that properties are of a required type which should make everything a lot cleaner.

I will need to do some testing to see if this would actually work the way that I expect it to, although that might have to wait until the porting effort is closer to being finished and I start prototyping. This is the only aspect that I think may be a little tricky to initially get my head around on this port.

Final thoughts

I’ve never kept a development log before, really; the closest I’ve ever gotten is probably the comments in my VCS checkins (I tend to be a prolific committer). Besides anything else, Devember is going to be a good way to develop a style for this sort of thing.

Onward to day 2!