Hi all,
Firstly, I don't intend this for PHP 7.0 strictly.
PHP is made for Web. It means PHP is made for interacting other
systems/data. Currently, we only have "int" and "float" strictly bounded
to native "unsigned int" and "IEEE 754 double". This causes problems
for interacting other systems/data.
Conversion to native data type causes problem like RFC 7159 "6 Numbers"
points out.
https://tools.ietf.org/html/rfc7159
PHP's "int" is more limited because safe value is least common and it's
signed 32 bit integer.
To resolve this issue, how about to have
- is_digits() and digits type for digits only inputs(integer like string)
-
is_numeric()and numeric type for float like string
These check if variable contains only digits or float like string.
It's pseudo type, but it prevents developers to specify "int"/"float" type
wrongly.
These may be extended to allow GMP int/float.
Having these make sense for a language made for interaction and make basic
type hint use intuitive. IMO.
I wouldn't like to write too long mail. My thoughts and concerns are in my
blog
mostly.
http://blog.ohgaki.net/php7-is-going-to-be-strictly-typed-language-will-this-work
http://blog.ohgaki.net/dont-use-php7-type-hint-for-external-data
Any comments?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
You know, given how worried you seem to be about this issue, could you
booby trap your so that if the developers use the wrong type (int vs.
string) the program throws fatal errors with nasty error messages that
explain how much trouble the developer is in at the userland code level?
While I like the of protecting idiot developers from themselves, I'm still
not sure that this isn't a half solutions that just hide the pieces of the
problem that it doesn't solve.
I don't think we can solve the problem of developers not writing code
correctly or QA would mostly be out of job (instead of being a growth
segment).
How about a full type system that would make Java programmer scream? I'm
sure with a bit of thought we can make one heavier than Java.
Walter
Hi all,
Firstly, I don't intend this for PHP 7.0 strictly.
PHP is made for Web. It means PHP is made for interacting other
systems/data. Currently, we only have "int" and "float" strictly bounded
to native "unsigned int" and "IEEE 754 double". This causes problems
for interacting other systems/data.Conversion to native data type causes problem like RFC 7159 "6 Numbers"
points out.
https://tools.ietf.org/html/rfc7159
PHP's "int" is more limited because safe value is least common and it's
signed 32 bit integer.To resolve this issue, how about to have
- is_digits() and digits type for digits only inputs(integer like string)
is_numeric()and numeric type for float like stringThese check if variable contains only digits or float like string.
It's pseudo type, but it prevents developers to specify "int"/"float" type
wrongly.
These may be extended to allow GMP int/float.Having these make sense for a language made for interaction and make basic
type hint use intuitive. IMO.I wouldn't like to write too long mail. My thoughts and concerns are in my
blog
mostly.http://blog.ohgaki.net/php7-is-going-to-be-strictly-typed-language-will-this-work
http://blog.ohgaki.net/dont-use-php7-type-hint-for-external-dataAny comments?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Hi Walter,
You know, given how worried you seem to be about this issue, could you
booby trap your so that if the developers use the wrong type (int vs.
string) the program throws fatal errors with nasty error messages that
explain how much trouble the developer is in at the userland code level?While I like the of protecting idiot developers from themselves, I'm still
not sure that this isn't a half solutions that just hide the pieces of the
problem that it doesn't solve.I don't think we can solve the problem of developers not writing code
correctly or QA would mostly be out of job (instead of being a growth
segment).How about a full type system that would make Java programmer scream? I'm
sure with a bit of thought we can make one heavier than Java.
Java is not PHP.
Java does not have 32 bit int on 32 bit machines, 64 bit int on 64 bit
machine.
Java has concrete byte, short, int, long type. It's whole different story.
BTW, I noticed that mt_rand() behavior has changed to raise E_WARNING for
too large numbers.
This is good change because PHP is known to generate very weak random
number with invalid
min/max.
[yohgaki@dev ~]$ php-5.6 -r "var_dump(mt_rand(222,
'99999999999999999999999'));"
int(115282844144104926)
[yohgaki@dev ~]$ php-7.0 -r "var_dump(mt_rand(222,
'99999999999999999999999'));"
Warning: mt_rand() expects parameter 2 to be integer, string given in
Command line code on line 1
NULL
This behavior is much better. I mean E_WARNING and return NULL from
function is
much easier than dealing with E_RECOVERBLE_ERROR.
Strict mode may stay as it is, but shouldn't we have consistent behavior?
Internal function raises E_WARNING for too large int while user function
raises E_RECOVERBLE_ERROR
does not make much sense.
Regards,
P.S.
With strict_types=1, mt_rand() gives
Fatal error: mt_rand() expects parameter 2 to be integer, string given in
/home/yohgaki/t.php on line 3
--
Yasuo Ohgaki
yohgaki@ohgaki.net
In C, the int data type is defined as being at least 16 bits in size. Long
is defined as being at least 32 bits and long long is defined as being at
least 64 bits in size. The standard further recommends that the size of int
be the most natural and efficient for the processor (i.e. 16 on 16 bit
processors, 32 on 32 bit processors, 64 on 64 bit processors). The C99
standard added standard types for integers that had defined sizes (the
8bit, 16 bit, 32 bit and 64 bit integer types). In Java, the sizes are
fixed, but I think you missed my point as there are multiple integer types
not that they change sizes.
PHP was written to use the first suggestion (integers being the natural
data size of 32 or 64 bit). To keep PHP simple, there is a desire to not
introduce several different integer sizes in PHP. Your right, this does
make it harder for people that want to use 64 bit integers on 32 bit
systems as 64 bit integers. For those people, they will have to use strings
or bignum. Given the lack of desire for this addition, the relatively small
number of PHP developers, and the idea that this is a legacy issue, I'd be
surprised if you. could get support for this.
Adding a numeric pseudo type will not fix abuse, it will only change the
abuse. I don't think it is worth the effort. I also think it might a
slippery slope to lots of other pseudo types and other half ideas that will
add complexity to the language without much in the way of benefit.
The mixing of types, casts and validations can cause problems. I don't see
how adding pseudo types will actually fix this as this appears to a
validation problem and not a typing problem.
Hi Walter,
You know, given how worried you seem to be about this issue, could you
booby trap your so that if the developers use the wrong type (int vs.
string) the program throws fatal errors with nasty error messages that
explain how much trouble the developer is in at the userland code level?While I like the of protecting idiot developers from themselves, I'm
still not sure that this isn't a half solutions that just hide the pieces
of the problem that it doesn't solve.I don't think we can solve the problem of developers not writing code
correctly or QA would mostly be out of job (instead of being a growth
segment).How about a full type system that would make Java programmer scream? I'm
sure with a bit of thought we can make one heavier than Java.Java is not PHP.
Java does not have 32 bit int on 32 bit machines, 64 bit int on 64 bit
machine.
Java has concrete byte, short, int, long type. It's whole different story.BTW, I noticed that
mt_rand()behavior has changed to raiseE_WARNINGfor
too large numbers.
This is good change because PHP is known to generate very weak random
number with invalid
min/max.[yohgaki@dev ~]$ php-5.6 -r "var_dump(mt_rand(222,
'99999999999999999999999'));"
int(115282844144104926)
[yohgaki@dev ~]$ php-7.0 -r "var_dump(mt_rand(222,
'99999999999999999999999'));"Warning:
mt_rand()expects parameter 2 to be integer, string given in
Command line code on line 1
NULLThis behavior is much better. I mean
E_WARNINGand returnNULLfrom
function is
much easier than dealing with E_RECOVERBLE_ERROR.Strict mode may stay as it is, but shouldn't we have consistent behavior?
Internal function raisesE_WARNINGfor too large int while user function
raises E_RECOVERBLE_ERROR
does not make much sense.Regards,
P.S.
With strict_types=1,mt_rand()givesFatal error:
mt_rand()expects parameter 2 to be integer, string given in
/home/yohgaki/t.php on line 3--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Hi Walter,
Adding a numeric pseudo type will not fix abuse, it will only change the
abuse. I don't think it is worth the effort. I also think it might a
slippery slope to lots of other pseudo types and other half ideas that will
add complexity to the language without much in the way of benefit.
Pseudo type is not abuse if it's there.
Almost all PHP programs treated external values as string. PHP handled it
somewhat nicely by type juggling.
In PHP, integer like values are treated
signed 32 bit int: 32 bit CPU
signed 53 bit int: 32/64 bit CPU (IEEE 754 double)
signed 64 bit int: 64 bit CPU
arbitrarily int: 32/64 bit CPU (string digits is good enough for
databases/etc IDs)
If arithmetic is needed, we could assume it has at least signed 53 bit int.
If arithmetic is not needed, we could assume
arbitrarily int. I usually don't need integer arithmetic correctness much
because most arithmetic are very
simple. Examples are adding/subtracting date, stock, counter which will
never exceeds signed 53 bit int range.
On contrast, I need strict correctness for record IDs. Valid IDs should
never raise error/exception.
Use of type "int" type hint reduces reliable range to signed 32 bit int.
The mixing of types, casts and validations can cause problems. I don't see
how adding pseudo types will actually fix this as this appears to a
validation problem and not a typing problem.
Validations should not cause problems. If it does, the way validating data
is wrong.
I understand what's wrong with "int" type hints, yet I have to fight
against temptation
using it when signed 64 bit int is enough for my code/system. Vast majority
of
PHP programmers would use "int" type hint without considering the
limitation and
consequence.
Anyway, we need at least numeric value validation (safe cast) function.
Without it,
strict_types=1 is harmful especially because people will just use casts
which hides
problem is their code.
I don't expect PHP's "int" type hint accept arbitrarily numbers even when
GMP int
is fully integrated. PHP is made for web and interaction. JSON supports
"numeric"
that has undefined(unlimited) precisions, databases support huge numbers.
Advocating
users to use "string" type hint for these seems impossible. We'll see the
result soon.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
For recordID parameters, I think the only to get what you want is use a
class and strongly type the objects. I deal daily with code that assumes
things that look like integers are integers. As far as integers go, 123456
and 000123456 are the same. As record keys, they don't have to be the same
(it is a bad design). Without adding a 64 int type to 32 bit PHP, you can
not fix this in 32 bit land and keep PHP looking like PHP.
I guess this breaks down to the following two choices: In 32 bit PHP, what
is the proper response to an API that uses 64 integers? Should the values
be treated as strings or as integers. If treated as strings, they they can
perform all the functions of database keys and any other purpose that
treats them as tokens. If used as integers, then you set your code up for
failure. Anybody that casts or coverts them to ints has just set themselves
up for failure at some point in the future.
I'm not sure how we can fix the problem of people that see something that
looks like an int so they want to call it an int, regardless of the fact
that that is the wrong thing to do. But I don't blame you, as this sort of
mislabeling happens throughout society (just look at politics and the
misuse of labels there).
As far as the idea that most PHP won't use type hints correctly (to me,
that reads "Most PHP programmers don't care about the code they write or
are too stupid to see the problems"), maybe we could require that PHP
programmers get a license that requires that they understand how to use the
language correctly. Maybe we could fire them or ask them to use a simpler
language that doesn't require them to understand important details. I hear
you can still get BASIC.
If you don't want you code to break when you 64 bit ints, either check for
size type and blowup/give a warning that your library is not compatible
with 32 bit ints or face the reality that the keys must be stings or
objects if you want your code to run without errors on 32 & 64 systems
without error.
Hi Walter,
Adding a numeric pseudo type will not fix abuse, it will only change the
abuse. I don't think it is worth the effort. I also think it might a
slippery slope to lots of other pseudo types and other half ideas that will
add complexity to the language without much in the way of benefit.Pseudo type is not abuse if it's there.
Almost all PHP programs treated external values as string. PHP handled it
somewhat nicely by type juggling.In PHP, integer like values are treated
signed 32 bit int: 32 bit CPU
signed 53 bit int: 32/64 bit CPU (IEEE 754 double)
signed 64 bit int: 64 bit CPU
arbitrarily int: 32/64 bit CPU (string digits is good enough for
databases/etc IDs)If arithmetic is needed, we could assume it has at least signed 53 bit
int. If arithmetic is not needed, we could assume
arbitrarily int. I usually don't need integer arithmetic correctness much
because most arithmetic are very
simple. Examples are adding/subtracting date, stock, counter which will
never exceeds signed 53 bit int range.On contrast, I need strict correctness for record IDs. Valid IDs should
never raise error/exception.Use of type "int" type hint reduces reliable range to signed 32 bit int.
The mixing of types, casts and validations can cause problems. I don't see
how adding pseudo types will actually fix this as this appears to a
validation problem and not a typing problem.Validations should not cause problems. If it does, the way validating data
is wrong.I understand what's wrong with "int" type hints, yet I have to fight
against temptation
using it when signed 64 bit int is enough for my code/system. Vast
majority of
PHP programmers would use "int" type hint without considering the
limitation and
consequence.Anyway, we need at least numeric value validation (safe cast) function.
Without it,
strict_types=1 is harmful especially because people will just use casts
which hides
problem is their code.I don't expect PHP's "int" type hint accept arbitrarily numbers even when
GMP int
is fully integrated. PHP is made for web and interaction. JSON supports
"numeric"
that has undefined(unlimited) precisions, databases support huge numbers.
Advocating
users to use "string" type hint for these seems impossible. We'll see the
result soon.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Hi!
- is_digits() and digits type for digits only inputs(integer like string)
is_numeric()and numeric type for float like string
This is not what types are in PHP, and not what they should be, IMO. If
you want to assign arbitrary checks to a variable, I would suggest using
a class with a suitable constructor. If you think it's too slow (meaning
you are doing very heavy in-memory data processing and nothing else),
make an extension - it would be roughly the same speed as native PHP
types. If you want it to be extensible - then you may be looking for
something like pre/post conditions and DbC, but this is another story
for which we need proper RFCs, etc.
However, calling random combination of native types, objects and string
constraints "type" because somewhere there's use case for it does not
look like a good design for a language. It's too random and ad-hoc.
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
On Tue, May 12, 2015 at 2:19 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
- is_digits() and digits type for digits only inputs(integer like
string)is_numeric()and numeric type for float like stringThis is not what types are in PHP, and not what they should be, IMO. If
you want to assign arbitrary checks to a variable, I would suggest using
a class with a suitable constructor. If you think it's too slow (meaning
you are doing very heavy in-memory data processing and nothing else),
make an extension - it would be roughly the same speed as native PHP
types. If you want it to be extensible - then you may be looking for
something like pre/post conditions and DbC, but this is another story
for which we need proper RFCs, etc.
I agree that validation and DbC is far better than resolution I proposed
here.
I guess DbC will not prevent users from abusing type hints, though.
However, calling random combination of native types, objects and string
constraints "type" because somewhere there's use case for it does not
look like a good design for a language. It's too random and ad-hoc.
If we aren't going to change any, we need large warning in the manual,
explain nature of external data, compatibility issues between 32 bit and
64 bit CPU, what kind of data is appropriate for native type hints, etc.
It's not a difficult job to do.
How about have functions check if value fits to certain data types,
32 bit int, 64 bit int and IEEE double?
We may add/extend is_digits()/is_numeric() for this. It would be handy
for DbC also.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote on 14/05/2015 06:19:
I guess DbC will not prevent users from abusing type hints, though.
They'll only "abuse" them in exactly the same way they currently "abuse"
existing checks and casts.
e.g. $id = intval($_GET['id']); looks perfectly reasonable to most
people, but if you want to use a 64-bit ID on a 32-bit system, you will
consider that a bug. If someone uses an int typehint for the same
purpose then it is, equally, a bug.
The result of one will probably be retrieving the wrong data, and thus
potential leak or corruption; the result of the other will probably be a
fatal error, which at least stops the broken code in its tracks.
Regards,
Rowan Collins
[IMSoP]
Hi Rowan,
On Thu, May 14, 2015 at 6:19 PM, Rowan Collins rowan.collins@gmail.com
wrote:
Yasuo Ohgaki wrote on 14/05/2015 06:19:
I guess DbC will not prevent users from abusing type hints, though.
They'll only "abuse" them in exactly the same way they currently "abuse"
existing checks and casts.e.g. $id = intval($_GET['id']); looks perfectly reasonable to most people,
but if you want to use a 64-bit ID on a 32-bit system, you will consider
that a bug. If someone uses an int typehint for the same purpose then it
is, equally, a bug.The result of one will probably be retrieving the wrong data, and thus
potential leak or corruption; the result of the other will probably be a
fatal error, which at least stops the broken code in its tracks.
I saw such buggy casts too many times in my code auditing experience.
Since strict_types=1 requires "certain type", I'm expecting more buggy casts
with it.
We need safe validation functions so that we can advocate users
do proper validation rather than buggy casts. IMHO.
There was one attempt
https://wiki.php.net/rfc/safe_cast
but it failed. We need new one.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
is_numeric()and numeric type for float like string
FYI, there's ctype_digit($s) and preg_match('/^[0-9]+$/s', $s);
Adding more functions would be only confusing, I think.
--
Lauri Kenttä
To resolve this issue, how about to have
- is_digits() and digits type for digits only inputs(integer like
string)is_numeric()and numeric type for float like string
Firstly, these functions already exist; the first is called ctype_digit and works as described, the second has quite a broad definition but is basically the same as you're suggesting.
Secondly, this doesn't solve the problem you are claiming to have, namely validating values which are safe for external uses, because these checks are far too loose.
For instance, valid input for a 64-bit signed integer in a database could include:
- any PHP native integer (assuming nobody builds with 128-bit ints!)
- any string consisting of all digits, such that when interpreted as an integer the value won't exceed 2^64-1
- any string consisting of a '-' followed by digits, such that the magnitude of the integer interpretation wouldn't exceed 2^64
- any PHP float with no fractional part, maybe capped to a magnitude less than 2^53 for safety
For an unsigned integer, there's one less string case, and extra checks to the float and int cases to exclude negative values.
This is full data validation, not type checks, and belongs in ext/filter or similar as a suite of filters for different foreign types.
One approach to implement it would be to perform basic pattern validation with is_numeric or a simple regex, promote to a GMP object, and then range check based on the required type.
A "numeric type" would actually just be a piece of metadata attached to the variable saying that this function had been run, since the underlying representation would be unchanged. A bit like Perl's "taint tracking", but much more complicated.
Regards,
Rowan Collins
[IMSoP]
For instance, valid input for a 64-bit signed integer in a database could include:
- any PHP native integer (assuming nobody builds with 128-bit ints!)
- any string consisting of all digits, such that when interpreted as an integer the value won't exceed 2^64-1
- any string consisting of a '-' followed by digits, such that the magnitude of the integer interpretation wouldn't exceed 2^64
- any PHP float with no fractional part, maybe capped to a magnitude less than 2^53 for safety
BUT
In INTEGER in a database is 32 bit and will remain 32 bit, just as
SMALLINT is 16 bit ... 64 bit is BIGINT and so the whole concept of
simply ignoring 32 bit and handling them instead as 64bit is wrong!
So type hints are broken before they start!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
For instance, valid input for a 64-bit signed integer in a database
could include:
- any PHP native integer (assuming nobody builds with 128-bit ints!)
- any string consisting of all digits, such that when interpreted as
an integer the value won't exceed 2^64-1- any string consisting of a '-' followed by digits, such that the
magnitude of the integer interpretation wouldn't exceed 2^64- any PHP float with no fractional part, maybe capped to a magnitude
less than 2^53 for safetyBUT
In INTEGER in a database is 32 bit and will remain 32 bit, just as
SMALLINT is 16 bit ... 64 bit is BIGINT and so the whole concept of
simply ignoring 32 bit and handling them instead as 64bit is wrong!
Nobody is "ignoring 32-bit". If you want to validate that a variable will fit in a 32-bit signed integer, or a 16-bit unsigned one, or whatever else, you need to range-check it as above. Just as you would validate a variable which you expected to contain an email address before you used it in an SMTP header.
Type hints are not intended for validating data that is entering or leaving PHP from or to other systems, they are only relevant when passing data from one part of a PHP system to another. On any given install of PHP, two libraries communicating with each other by function calls will agree on a definition of "int", because they are in the same process, and that is all that is needed for an "int" type hint to be meaningful.
Regards,
Rowan Collins
[IMSoP]
Type hints are not intended for validating data that is entering or leaving PHP from or to other systems, they are only relevant when passing data from one part of a PHP system to another. On any given install of PHP, two libraries communicating with each other by function calls will agree on a definition of "int", because they are in the same process, and that is all that is needed for an "int" type hint to be meaningful.
I think that perhaps this is a key point that needs to be fully
documented before PHP7 is released. That type hints are essentially NOT
to be used for data validation may not be obvious to many who are
planning to 'convert' to using them?
However I still don't see how one one can handle data handed over
internally without also providing a mechanism to ensure the right range
of value is maintained through the system. If a library produces results
that are out of range of the target channel then simply establishing
that it's a valid number is of limited use.
It IS the handling of data validation as a central service that is
needed, and why would one not then use that for the internal data
handling as well?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Type hints are not intended for validating data that is entering or
leaving PHP from or to other systems, they are only relevant when
passing data from one part of a PHP system to another. On any given
install of PHP, two libraries communicating with each other by function
calls will agree on a definition of "int", because they are in the same
process, and that is all that is needed for an "int" type hint to be
meaningful.I think that perhaps this is a key point that needs to be fully
documented before PHP7 is released. That type hints are essentially NOT
to be used for data validation may not be obvious to many who are
planning to 'convert' to using them?
Perhaps, but this is exactly the same purpose type hints have in other languages, AFAIK. Types in different systems have different meanings, and no one language can remove those differences.
However I still don't see how one one can handle data handed over
internally without also providing a mechanism to ensure the right range
of value is maintained through the system. If a library produces
results
that are out of range of the target channel then simply establishing
that it's a valid number is of limited use.
It is of limited use in some situations, yes. Knowing that a value is an integer as defined by PHP is entirely sufficient if the task at hand is to manipulate it mathematically as an integer. Knowing that a value is a string is of limited value if the task at hand is to use it as an e-mail address. Database input of integers is more similar to the second case than the first.
It IS the handling of data validation as a central service that is
needed, and why would one not then use that for the internal data
handling as well?
It may be that that is what YOU need, but that doesn't make other people's needs irrelevant.
It is already possible to pass around, and type hint for, any class of object, so you could for instance have a DatabaseID class. PHP's lack of operator overloading makes that less appealing, perhaps, but it would work.
In some languages, you can simply declare "range" or "domain" types, which are scalar types annotated with upper and lower bounds, or other limits. Ada apparently encourages this, for instance. The problem with doing so in PHP is that a variable's type is not fixed or declared, so in something as simple as $a = $b + 1, should $a have the same range as $b or not?
Of course, if you want "PHP, but with a stricter type system", then you can always use Hack. :)
Regards,
Rowan Collins
[IMSoP]
It is already possible to pass around, and type hint for, any class of
object, so you could for instance have a DatabaseID class. PHP's lack
of operator overloading makes that less appealing, perhaps, but it
would work.
Incidentally, it's still not the type hint that's performing validation here - that would go in the constructor of the object, I guess. Rather, the type hint holds the promise that the validation has already happened somewhere else.
It is already possible to pass around, and type hint for, any class of
object, so you could for instance have a DatabaseID class. PHP's lack
of operator overloading makes that less appealing, perhaps, but it
would work.
Incidentally, it's still not the type hint that's performing validation here - that would go in the constructor of the object, I guess. Rather, the type hint holds the promise that the validation has already happened somewhere else.
That most good libraries already have the validation code is my point
here. Either the variable has already been validated, so the type hint
is not relevant. OR the data still needs validating in which case only
'string' is now usable? With any pre-processing now requiring a switch
back to string ... this is where I'm having problems seeing how if
someone switches a library to using strict type hinting internally that
will not have an impact on using the same library as it is currently
being used without type hinting.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
For instance, valid input for a 64-bit signed integer in a database
could include:
- any PHP native integer (assuming nobody builds with 128-bit ints!)
- any string consisting of all digits, such that when interpreted as an
integer the value won't exceed 2^64-1- any string consisting of a '-' followed by digits, such that the
magnitude of the integer interpretation wouldn't exceed 2^64- any PHP float with no fractional part, maybe capped to a magnitude
less than 2^53 for safetyBUT
In INTEGER in a database is 32 bit and will remain 32 bit, just as
SMALLINT is 16 bit ... 64 bit is BIGINT and so the whole concept of
simply ignoring 32 bit and handling them instead as 64bit is wrong!
So type hints are broken before they start!
You should handle sanitizing data for you external storage specific to the
external storage you're using and not expect the language to do it for you.
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
For instance, valid input for a 64-bit signed integer in a database
could include:
- any PHP native integer (assuming nobody builds with 128-bit ints!)
- any string consisting of all digits, such that when interpreted as an
integer the value won't exceed 2^64-1- any string consisting of a '-' followed by digits, such that the
magnitude of the integer interpretation wouldn't exceed 2^64- any PHP float with no fractional part, maybe capped to a magnitude
less than 2^53 for safetyBUT
In INTEGER in a database is 32 bit and will remain 32 bit, just as
SMALLINT is 16 bit ... 64 bit is BIGINT and so the whole concept of
simply ignoring 32 bit and handling them instead as 64bit is wrong!
So type hints are broken before they start!--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
Yes, you understand the problem. PHP type hints are for PHP variables and
PHP types. External applications that have types with the same names and
different sizes can not use PHP type hints. Until and unless a majority
block of voters appears and is willing to add a full suite of types that
match external applications (8, 16, 32, 64, etc bit Integers, 32, 64, 80
bit floats, plus maybe the decimal types and the bignum types), you will
not be able to create scalar variables that track the types of external
data types. As some of the major committers are actually against adding
this sort of complexity to PHP, it is unlikely to happen.
For external data types, I don't see a good path other than classes for
tracking the data types.
How about a different type of RFC. How about adding the ability to add your
own scalar types to the language. Then people that want to write C++/Java
in PHP can define all the types they like. I'm sure that It could be done
in time for a PHP 8 or PHP 9.
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis