Mystery types in interacitons between squiffy and JS

Okay, I've got a bunch of functions running in my new game. However, once I got into my effort to round off things, darker issues were revealed, especially working with JS and squiffy in tandem.

If you had this code where the squiffy value of "b" was supposedly 5, you might see...

    var a=4;

    a = a + get("b");

using window.alert fields, I've seen this value come up, not as 9, but as 45 (i.e. it treats the squiffy value as text and concatenates the two together). I don't know at what step along the way squiffy assumes its value is a string. What I'd like to do is force it back to numeric for the arithmetic operations I must perform.


If you're setting it using @set, it will be set as a string. Squiffy just splits the line where the = is and assigns all the characters to the right of it to the attribute.

You can use the unary + operator to convert a value to a number. For example:

    var b = +get("b")

The + with no value to the left of it forces the number to the right of it to be treated as a number. But using this as part of an addition could get confusing to read. A more intuitive answer would be:

    a = a + Number(get("b"))


    a = a + parseInt(get("b"))

(Note: if I remember correctly, Number() is actually the constructor for a Number object, rather than a native int. In 99% of cases this doesn't make any kind of difference; unless you want to do weird things like changing a numbers truthiness)

I finally ran it down to the toFixed(1) command. I'd add a JS and a squiffy integer before using it and it would work fine. If I manipulated the value with toFixed, it would concatenate the JS and squiffy (and yes, that's what the JS manual said it would do).

I don't use @set, and prefer {@var} assignments (mainly for reasons given on the other active thread - the @set command is spooky).

Of course, I tried to prove this by duplicating the code in a test file and no, it wouldn't fail in the limited case. Right now, to handle roundoffs, I'm doing what I did 40 years ago in fortran - multiplying by 10, trunking, then dividing by 10. We'll see if that works.

Today was a long day of frustration in squiffyLand.

Log in to post a reply.