Looking at JavaScript which acts quite similarly to the proposed
approach, the Number methods [1] are not many and not often useful,
but still they exist. What happens if you do "3.3"->ceil() ? If ceil()
exists only in \numeric, you could say autoconvert, but if it exists
in both \string and \numeric we have a problem, so the only sensible
way is to drop type juggling for those autoboxed objects imo. Which is
also what JS does btw. If you have an ambiguous value on your hands,
you should cast it (x.toString() or parseInt(x)) first and then call
what you want to call on it. Another interesting to note is that JS
doesn't allow method calls directly on numbers - 3.toPrecision(2) for
example is a syntax error, you have to put it in a var first. I guess
it's not a problem since you should just inline the value you want
anyway, the Number methods don't do super fancy things.
Anyway, I hope this helps, my point is just that you shouldn't forget
to check out how other languages solved the issue before hitting the
wall ourselves. Not saying we have to do it all like JS, but they have
something that works, so it's worth studying.
Jordi Boggiano
We could use the library organization of JS, in that purely math-related methods like 'ceil', 'sin' etc., constants like PI, E etc. will be in namespace \math and take any scalar numeric input. As a lot of them take more than one arguments, and the arguments are sometimes commutative, it makes less sense to present those ones in particular as methods.
The few number methods that make sense as methods can then be in the scalar API. Almost like JS but not quite. Since's PHP's interpretation of types is slightly different than JS, we can surely take a page from JS, that's good (and I support it) but it needs to be nudged more towards PHP's PoV.
Re. number literals, (3).toPrecision(2) works in JS, I guess they wanted to avoid some ambiguity in the parser, ex. 3.0.toPrecision(2).
Stan Vass