On Aug 23, 10:32 am, "Mike Fern" <[EMAIL PROTECTED]> wrote:

> Hi Pops,
> This is interesting. Maybe it's because $('start').value is considered
> as string instead of integer? What was the property type from alert
> anyway?

Hi Mike,

I just finished posting an analysis that shows in JS theory, it isn't
a bug.  :-)

Its one of those nice powerful things about the JS langauge where you
don't need to type case and it will "figure" out things for you base
on the variable type.

For our intepreter, I do similar automatic type casting logic as well
and it the same based on the input of dyadic operators (operators with
input on both sides as oppose to monadic with one right side input).
The difference is that I test for what the string converts to, not
that it is a string type.  in other words, if the left side string is
a alphanumeric, then it is a number for operators.

Example.  The conversion of both sides input determines the type of
operation for the operator:

    string operator string   =>  string operation
    string operator number =>   string operation
    number operator number =>   numeric operation
    number operator string =>   numeric operation, i.e., number
operator atoi(string)

I should of known what JS was doing. :-)

But you bring up a point to explore.  What if you have this?

    1*x += 1*y

in this case, you help the interpreter type case both sides.

But I don't think that would be a legal JS syntax. Lets try this under
firebug:

   x = "100";
   y = "200";
   1*x += 1*y;
  console.log("x = "+x);

invalid assignment left-hand side
   1*x += 1*y

Interesting. :-)

--
HLS

Reply via email to