Thanks for raising this. Iāve read the linked RemObjects units-of-measure article and thought carefully about the points made here. This is a cool feature.
A complete units-of-measure system is impressive, but it would introduce a considerable amount of language and compiler work. I donāt think Objo needs all of that at present.
However, the point about time-related APIs is very compelling. Having to remember whether a timeout, delay, or interval expects milliseconds or seconds is exactly the sort of avoidable ambiguity Objo can fix.
Iām therefore implementing a focused built-in Duration type and migrating all of Objoās time-based APIs to use it. Code will look like this:
Task.Delay(500.Milliseconds())
System.Sleep(2.Seconds())
timer.Interval = 250.Milliseconds()
connection.Timeout = 30.Seconds()
The same shorthand will work with variables and fractional values:
delay.Milliseconds()
1.5.Seconds()
Duration will support the usual arithmetic, comparisons, and conversions such as TotalMilliseconds and TotalSeconds. APIs where āno timeoutā was previously represented by the rather ambiguous value 0 will use the explicit Duration.Infinite.
Iām planning to make this a clean breaking change. I donāt want to permanently double the API surface with old numeric overloads alongside new Duration overloads, nor add implicit conversions that allow ambiguous code to continue compiling.
To make that practical, Objo Studioās analyser will understand the old API (once I fix it!). It will report the unit previously expected and suggest the correct replacement. There will also be a project migration command that previews the proposed edits and can apply the safe ones across the project. Cases requiring judgement will be identified for review rather than silently changed.
For example, it will know that the old Task.Delay(500) meant milliseconds and suggest:
Task.Delay(500.Milliseconds())
It will also understand APIs that previously used seconds and convert those appropriately.
This gives Objo the genuinely useful part of units of measure without committing Objo to a large general-purpose units framework. It should also give Objo a much cleaner foundation for future APIs involving delays, timeouts, intervals, audio positions, and elapsed time.
Iām working on this now. Once the migration tooling is ready, Iād be particularly interested in trying it against some real existing projects to see whether there are patterns the analyser has missed.