In the previous instalments of this little series, I looked at the
motivation for and
design choices behind a Scala library to use the type system to eliminate (or at least massively reduce) the incidence of errors when dealing with times here on planet Earth.
As is often the case with these things, the motivator was a real-life project that would benefit from such a library. While I can't share the code of that project, the library is
up on Github right now, and you can add the
JAR as a dependency to your SBT-driven project in both Scala 2.10 and 2.11 flavours.
So what did I miss when going from an idealised, clean-slate design to something a real-life application can use?
Quite a lot. Let's have a look.
Once you're strongly-typed anywhere, you have to be strongly-typed everywhere
Previously, I was representing instants and times using a mixture of
Long or
org.joda.time.DateTime.
I couldn't believe how quickly switching to
TimeInZone[TZ] resulted in that
[TZ] getting into
everything - for better or worse.
Iteration 1; Naive, timezone-less DateTimes:
case class CarRace ( location: String, startTime:DateTime, endTime:DateTime )
// We forgot a timezone - now we'll get whatever the server defaults to...
val localRaceStart = new DateTime(2015, 7, 5, 13, 0) // July 5, 2015, 1pm
val localRaceEnd = new DateTime(2015, 7, 5, 15, 0) // July 5, 2015, 3pm
// Highly likely to be WRONG:
val silverstoneGrandPrix = CarRace( "Silverstone", localRaceStart, localRaceEnd )
Iteration 2; Let's try to strongly-type the times:
case class CarRace ( location: String,
startTime:TimeInZone[_ <: TimeZone],
endTime:TimeInZone[_ <: TimeZone] )
This instance happens to be correct, but
CarRace doesn't enforce that races always start and end in the same timezone:
val britishGrandPrix = CarRace( "Silverstone",
TimeInZone[London](localRaceStart),
TimeInZone[London](localRaceEnd))
So we
could end up with this (a half-length race):
val brokenGrandPrix = CarRace( "Silverstone",
TimeInZone[London](localRaceStart),
TimeInZone[Paris](localRaceEnd))
Iteration 3; We have to enforce the timezone in the parent object:
case class CarRace[TZ <: TimeZone] ( location: String,
startTime:TimeInZone[TZ],
endTime:TimeInZone[TZ] )
So now we get good compile-time safety:
// This won't compile now!
val brokenGrandPrix = CarRace( "Silverstone",
TimeInZone[London](localRaceStart),
TimeInZone[Paris](localRaceEnd)) // error: type mismatch;
... but now we have to lug
[TZ] around everywhere...
val raceSeason = List[CarRace] // error: class CarRace takes type parameters
... and worse still, we often have to wildcard the "strong" type to actually
Get Stuff Done:
val raceSeason = List[CarRace[_ <: TimeZone]] // So what was the point of all this again???
Types are great - if you know them at compile-time
Although I knew the timezones that
some events would be occurring in, there's no way to know
all of the timezones of
all of the things:
// Seems reasonable enough ...
case class RaceWatcher[TZ <: TimeZone](name:String, watchingFrom:TZ)
OK so let's create and use a
RaceWatcher to find out when somebody needs to tune into a race in their timezone:
// Assume this gets passed in from the user's browser, or maybe preferences
val tz = TimeZone("America/New_York")
val chuck = RaceWatcher("Chuck", tz)
// Let's find out when Chuck needs to turn on his TV:
val switchOnAt = britishGrandPrix.startTime.map[chuck.watchingFrom]
// => error: type watchingFrom is not a member of RaceWatcher
We can't do that (without reflection). So in the end, we end up
stringly-typed instead of
strongly-typed;
I had to add
map(javaTimeZoneName:String) to the initial, "clean"
map[TZ]:
val switchOnAt = britishGrandPrix.startTime.map(chuck.watchingFrom.name)
// => TimeInZone[New_York] UTC: '2015-07-05T12:00:00.000Z' UTCMillis: '1436097600000' Local: '2015-07-05T08:00:00.000-04:00'
Timezones are still hard
My final observation is more particular to the domain of time rather than the use of types. They are still a mind-bender, and you still have to concentrate while working this area. Types can prevent obvious mismatches in assignments or parameters, but at the end of the day, the developer still needs to build up that mental picture of what they need to get done.
I will regard my first outing of
Arallon as a success though - most of the runtime problems I encountered in this first application were actually in the area of
time ranges rather than point-in-time errors. Which is why the next focus of Arallon will be type-safe representations of the concept:
- TimeSpanInZone - such as would be perfect for my car-race example above; and
- DayInZone - where a midnight-to-midnight 24-hour period in a timezone is the prime focus
