NavList:

>  It's an example of a "legacy code" problem --or less generously, it was built wrong in the first place. He defined a mathematical function in his code named "trunc" which has in recent years become the name of a standard javascript math function. 

Frank, you are spot on in pinpointing the source of the problem.

I, however would like to suggest slightly different interpretation on what happened.

Henning defines his trunc() function, which is perfectly fine. The new javascript defines trunc() method of Math object, which should not in any way interfere with user-defined trunc() if used correctly. This is where the problem comes. Henning uses obscure javascript with() operator, which allows to "abbreviate" object's method access.

Here is an excerpt (one of several) which causes problems in Henning's code:

...

with (Math)

{

// Mean longitude of the moon

Lmoon_mean = trunc(218.3164591+481267.88134236*TE-0.0013268*TE2+TE3/538841-TE4/65194000);

//Mean elongation of the moon

D = trunc(297.8502042+445267.1115168*TE-0.00163*TE2+TE3/545868-TE4/113065000);

Here in old javascript trunc() call would access user-defined trunc() function, in new javascript, where Math object has a method .trunc and because the call is within the scope of "with", the call to trunc refers actually refers to Math.trunc.

The lesson here is not so much "do not name your function trunc", because it is impossible to predict what new methods and objects will be added to javascript in future.

The lesson here is: "As a javascript programmer, do not use with() under any circumstances. Its inclusion in the language is generally accepted as a design mistake, and the best way to not get burned by it is not to use it. Just pretend it is not part of the language to begin with."

Whether we like it or not, javascript is everywhere. These days, if it has batteries -- it is likely it can run javascript.