integer
| Definition: |
integer identifier
-- or -- bool res = integer(object x) -- or -- int identifier -- or -- bool res = int(object x) |
| Description: |
This serves to define the integer type. int is just a simple alias of integer. You can also call it like an ordinary function to determine whether an object is an integer. |
| pwa/p2js: |
Supported, however JavaScript is a typeless language, with "integer i" being
mapped to "let /*integer*/ i;" and there are no run-time typechecks,
or at least they are very rare (see implementation notes below). An explicit hll/Phix "if integer(x)" and similar
expressions all work under pwa/p2js exactly as expected, except for:
Note that within JavaScript, an integer is +/-9,007,199,254,740,992 (ie 2^53). |
| Comments: |
When invoked as a function, returns 1 (true) if x is an integer, otherwise returns 0 (false).
On 32-bit, integers are whole numbers in the range -1,073,741,824 to +1,073,741,823 (-#40000000 to #3FFFFFFF, technically 31-bit) On 64-bit, integers are whole numbers in the range -4,611,686,018,427,387,904 to +4,611,686,018,427,387,903 (-#4000000000000000 to #3FFFFFFFFFFFFFFF, technically 63-bit) Obviously, however, any code which should work on both 32 and 64-bit should conform to the 32-bit limits. |
| Supplemental: |
In psym.e (part of the compiler), bool is a simple alias of integer, which does not validate that the value is true(1) or false(0) only -
instead, 0 is false, and any other value is deemed true. However there is a more rigorous version, boolean, defined in builtins/ptypes.e -
not an autoinclude but used/included by pGUI, mpfr, cffi, and hence indirectly
builtins\structs.e, so any of those will make it available. Obviously there is no harm whatsoever in storing a boolean in a bool or integer, and only rarely is there any advantage to using the former. Ideally boolean variables should (probably) begin with is/are/has or similar, eg isVisible/areEqual/hasEncryption in preference to visible/equal/encryption, or perhaps say bUgly (aka hungarian notation), with identifiers such as is_visible being more suggestive of a function that presumably returns a true/false result. Admittedly I tend to mix and mash those sort of rules and rather than getting too pedantic, try to focus on communicating the underlying intent as clearly as reasonably possible. The builtin constants true and false can and should be used for variables and parameters declared as type bool[ean], or, if you prefer, TRUE, True, FALSE, and False, are identical/aliases - mainly for compatibility with legacy code, but ultimately also one less thing (upper/lower case) that you have to remember, or fix. |
| Example 1: |
integer z = -1 |
| Example 2: |
if integer(y/x) then
puts(1, "y is an exact multiple of x")
end if
|
| Implementation: |
There are generic versions of the integer function implemented as :%opInt in builtins\VM\pType.e and :%opInt0 in builtins\VM\pJcc.e that
the compiler only invokes as a last resort, preferring instead to inline that functionality if the argument is known to be assigned or the
result variable, if any, is known to be an integer, ie does not require decref/dealloc. The compiler may also completely omit the test
and/or any related code, if type inference/propagation determines that the result will always be true or always false. As already mentioned, builtins/ptypes.e is where the supplemental types are defined. The file pwa/p2js.js defines integer() with an optional name parameter, which if not "" triggers unassigned or type check errors, but that (parameter) is not intended for or available from hll/Phix code, and only meant for use in manually hand-crafted replacements elsewhere in p2js.js, and in practice it ended up being invoked (that way) rather more sparingly than first predicted. |
| See Also: | atom, sequence, string, object, floor, puts, Core Language |
