I understand how doing something like `b = -a` mak...
# adobe
b
I understand how doing something like
b = -a
makes sense to flip the sign on a variable regardless of whether
a
is positive or negative. CF documents that both + and - perform unary arithmetic, so what should I be expecting from something like
b = +a
given
a
as a positive number or as a negative number?
This is a completely unrelated finding as I was exploring whether CF had support for the same numeric coercion as you see in JavaScript (e.g.
x = +"7"
yields
x
as a number type with a value of 7).
s
If it helps, you can think of
b = -a
as equivalent to
b = 0 - a
and
b = +a
as equivalent to
b = 0 + a
So they both implicitly do math and so they both implicitly convert their operand to a number.
b
in other words, if
a
= -10,
b = +a
is the same as
b = +-10
, which is -10
s
0 + -10
is indeed
-10
, yes.
b
then the documentation is slightly misleading as it says "Unary arithmetic: Set the sign of a number."
s
Adobe's documentation is misleading in general. It's very poorly written.
b
So I read that to mean if I flip the sign of -10, I'd end up with 10
s
If
a
is
-10
, then
-a
is
10
.
This is same as pretty much every other programming language out there in terms of unary
+
and unary
-
.
b
so the - actually does a flip, but + does... nothing?
s
Copy code
seanc@Sean-win-11-laptop:~$ node
> a = -10;
-10
> -a;
10
> +a;
-10
>
+a
doesn't do "nothing". Try this:
Copy code
a = "porcupine";
b = +a;
I think that will fail (it would fail in most languages)
b
I actually started down this road to see how CF would handle an expression like
+"10"
in JS, that'd give me a numeric 10
I guess I should clarify "nothing" in the realm of numbers
s
Oh, great, ACF produces
porcupine
for that but Lucee throws an exception that
porcupine
is not numeric. So I think ACF is broken there.
b
JS would return NaN, which is sensible
s
Well, as sensible as JS ever gets 🙂 Yes.
But ACF is broken IMO there. Lucee gets it right.
b
I can get on board with that statement