Decimal Time

I’m sure that there’s a time in everyones life when they get frustrated with the way we measure time. It may well have been very convenient for the Babylonians, with their love of fractions to have so many sixties all over the place (60 has a lot of divisors), but us modern folks tend to prefer doing things in terms of 10s or 100s.

The first time this annoyed me I quickly worked out what I thought a metric time system would look like, and wrote a program for my RiscPC in Basic that showed two clock faces, one for the standard and one for my version of decimalised time. Today I thought I’d revisit it, so here it is in javascript and canvas (if it doesn’t display the numbers on the clock face, that’s because you’re using an old browser).:

The second equivalent is 864 milliseconds, which allows us to have 100 second-equivalents in a minute-equivalent, 100 minute-equivalents in an hour-equivalent and 10 hour-equivalents in a day. I figured that days better stay the same length, because it’s handy for organisational purposes. I’ve put the 0 point at midnight, and because the whole 24 hours is once round a face, I’ve made the bottom half roughly correspond to night, and the top half roughly correspond to day.

I did come up with alternative names – I called the second equivalents sonds, the minute equivalents mintes and the hour equivalents hurs. 1 sond is 0.864 seconds, 1 minte is 1 minute 26 seconds, 1 hur is 2 hours 24 minutes. But the idea really is to stop using the current system and use a decimalised one so you don’t even really need to convert between the two.

It’s very easy to do maths with this system because numbers carry in the expected way, so 1:78:33 + 40:90 = 2:19:23.

When I first did it, the possibility of using it in everyday life was very slim – I would have needed a custom watch. Now I don’t have a watch, I use my phone instead, and it’d be fairly easy to write a widget for it that displays the decimalised time.

Inheritance and Javascript

Time for a technical post.

Javascript is a ‘prototype’ based language, and it means that inheritance is a different animal in Javascript than it is to more normal object oriented languages. You’ll see a million different ways of doing what seems a very standard thing. There are quite a few inheritance patterns that I’ve found on the web, often even using large and complex libraries.

The commonly seen inheritance pattern (even in impressive reference tomes) is this:

``` function Parent( args ) { // set up stuff } Parent.prototype.someMethod = function() { /* Do some work */ } function Child( args ) { // call the parents constructor with args // then set up your own stuff. } Child.prototype = new Parent(); Child.prototype.someMethod = function() { /* Do some work */ } ```

This works, in that the prototype chain is set up and attributes and methods are inherited. Where it doesn’t work is that you had to construct a new Parent at the time of the Childs definition rather than instantiation. Often the parents constructor simply doesn’t make sense taken in isolation like this, besides the frustration of having to call it again when the child is instantiated.

One suggestion was to set the prototype of the Child to the prototype of the parent.

``` function Parent( args ) { // set up stuff } Parent.prototype.someMethod = function() { /* Do some work */ } function Child( args ) { // call the parents constructor with args // then set up your own stuff. } Child.prototype = Parent.prototype; Child.prototype.someMethod = function() { /* Do some work */ } ```

But this doesn’t work because the prototypes are shared and the parents someMethod is corrupted by the client overriding it. But playing around the other day, we worked out a sneaky way around this, you can create an empty object which inherits from your parents prototype, and then inherit from that.
``` function Parent() { } Parent.classconstructor = function() { /* An object to represent the class */ } Parent.prototype = new Parent.classconstructor(); Parent.prototype.someMethod = function() { /* Do some work */ } function Child() { } Child.classconstructor = function() { /* An object to represent the class */ } Child.classconstructor.prototype = Parent.prototype; Child.prototype = new Child.classconstructor(); Child.prototype.someMethod = function() { /* Do some work */ } ```
A bit confusing maybe, but the inheritance chain is perfect, you don’t corrupt your parents prototypes when you assign methods to the Childs prototype.

You can wrap all this up into a utility method quite easily, which then doesn’t pollute your namespace.

``````
function extend(clazz, superclass) {
var intermediate = function() {};
intermediate.prototype = superclass.prototype;
clazz.prototype = new intermediate();
// you can do other stuff here to set up
// for example easy ways to call your super constructor,
// or super methods, or convenient ways of finding
}
```
```

and then you can use it very easily.

``` function Child() { } extend ( Child, Parent ); Child.prototype.someMethod = function() { /* Do some work */ } ```

So, all you javascript geniuses out there on the internet, let me know – is this a good pattern, or are there hidden dangers?