Re: [clock] behaves just slow (Re: [clock scan] behaves inconsistently in Tcl8.5

Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
> Andreas Leitgeb wrote:
>> Checking for the string "now" inside [clock format ...]
>> and [clock add ...] does *not* infer shimmering, if it
>> is done correctly: if an integer-representation exists,
>> then the "now"-check can safely be skipped. otherwise
>> if a string-rep exists (or has to be obtained, anyway,
>> as an interims-result), the "now"-check should be really
>> cheap.
>
> In 8.5, most of the [clock] subcommands are just procedures. This
> includes [clock format], [clock scan] and [clock add] (but not [clock
> seconds] or [clock clicks], for fairly obvious reasons). Avoiding
> shimmering in such circumstances is trickier.
>
The case is not lost.

The avoidance on shimmering could be passed on to
"string is wide" and the like (which would immediately
return true for objects with wide-representation). Only
if [string is wide ...] is not true, a check for "now"
would be made.
The aim should be compact legible user scripts, with least possible
slowdown, and no measurable slowdown for the old way of usage.

    if { [catch { expr { wide($clockval) } } result] } {
+ if {$clockval eq "now"} {
+ set clockval [clock seconds]
+ } else {
          return -code error \
            "expected integer but got \"$clockval\""
+ }
    }

Btw., why is catch used here in favour of [string is wide] ?
  and why is "result" given to catch, but not used?
Received on Thu Sep 29 14:35:55 2005