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?
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.
WebStorm is kind of annoying
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.
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 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.
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!