Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
I think there's a more fundamental flaw here than just pointing to 'numeric' as an alternative. The internal IS_* setting is meaningless for countless pieces of data floating around in PHP, arguably far more than the ones for which it truly represents the 'semantic' type. Continuing what Stas said, it's no coincidence our internal functions transparently translate arguments to the required types (except for the rare cases where it's not possible). The other course of action is to change the implementation so that it behaves like the one for internal functions - with emphasis on conversion instead of validation of IS_*. We can consider being more strict - and error-out on non-numeric strings instead of producing 0; If we were to start from scratch today, we'd probably do the same for internal functions. Encouraging the equivalent of strict is_*() checks is very inconsistent with both our entire internal functions library, as well as the common behavior of PHP. It doesn't come to say that it's not useful in some cases - but for these, using is_*() should be a suitable. Zeev At 20:40 01/07/2009, Ilia Alshanetsky wrote: Tom, Type hinting is optional you don't have to use it. However, the numeric type I've added specifically addresses that point. Ilia Alshanetsky CIO/CSO Centah Inc. On 2009-07-01, at 1:22 PM, Tom Boutell t...@punkave.com wrote: I expect this would be a problem for folks who are relying on the fact that they can parse configuration files and web inputs purely as strings, yet numeric fields containing string representations of numbers will actually behave as numbers if called upon to do so. Speaking of which, when I'm in a hurry and large numbers (or negative numbers) are not dangerous in that particular context, I sometimes validate a numeric field like this: $x = $_REQUEST['x'] + 0; And then assume $x will be a number - perhaps an obnoxious number, maybe even a huge floating point number with an exponent, but a number. Is there a flaw in that reasoning that I'm not aware of? On Wed, Jul 1, 2009 at 1:15 PM, Alain Williamsa...@phcomp.co.uk wrote: On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict ... Another desirable result of type hinting is that it would strengthen reflection ... one use of that would be automatic generation of WSDL files. This is something that I am currently struggling to do, not helped by the completely cr*p documentation of this - I am not talking about PHP documentation here by W3 other places :-( +1 to type hinting. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Sun, Jul 05, 2009 at 11:30:28AM +0300, Zeev Suraski wrote: I think there's a more fundamental flaw here than just pointing to 'numeric' as an alternative. The internal IS_* setting is meaningless for countless pieces of data floating around in PHP, arguably far more than the ones for which it truly represents the 'semantic' type. Continuing what Stas said, it's no coincidence our internal functions transparently translate arguments to the required types (except for the rare cases where it's not possible). The other course of action is to change the implementation so that it behaves like the one for internal functions - with emphasis on conversion instead of validation of IS_*. We can consider being more strict - and error-out on non-numeric strings instead of producing 0; If we were to start from scratch today, we'd probably do the same for internal functions. Encouraging the equivalent of strict is_*() Maybe that is something to consider: PHP 6: warn on non-numeric strings, dependent on something in php.ini PHP 7: error on non-numeric strings If someone has some code that goes: $six = 3 + 'three'; then is isn't doing what they intend, so an error would be helpful. The question is one of transition - breaking code that doesn't do input validation, hence for a transition to help the better programmers. As for the cr*p programmers - well their code was broken anyway. checks is very inconsistent with both our entire internal functions library, as well as the common behavior of PHP. It doesn't come to say that it's not useful in some cases - but for these, using is_*() should be a suitable. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi Ilia,
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org wrote:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.109
diff -u -p -a -d -u -r1.647.2.27.2.41.2.109 zend_compile.c
--- Zend/zend_compile.c 7 Jun 2009 15:46:51 - 1.647.2.27.2.41.2.109
+++ Zend/zend_compile.c 4 Jul 2009 17:20:50 -
@@ -1511,10 +1514,9 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, Default
value for parameters with a
class type hint can only be NULL);
}
}
- } else {
- cur_arg_info-array_type_hint = 1;
- cur_arg_info-class_name = NULL;
- cur_arg_info-class_name_len = 0;
+ break;
+
+ case IS_ARRAY:
So, to signify an array type hint, we used to use 1, and we now use
IS_ARRAY, which is 4. I'm not 100% sure that's an ABI problem, but I
just wanted to check.
if (op == ZEND_RECV_INIT) {
if (Z_TYPE(initialization-u.constant) ==
IS_NULL ||
(Z_TYPE(initialization-u.constant) == IS_CONSTANT
!strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
cur_arg_info-allow_null = 1;
@@ -1522,6 +1524,56 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, Default
value for parameters with
array type hint can only be an array or NULL);
}
}
+ break;
+
+ /* scalar type hinting */
+ case IS_BOOL:
+ case IS_STRING:
+ case IS_LONG:
+ case IS_DOUBLE:
+ case IS_RESOURCE:
+ case IS_NUMERIC:
+ case IS_SCALAR:
+ case IS_OBJECT:
+ if (op == ZEND_RECV_INIT) {
+ if (Z_TYPE(initialization-u.constant) !=
class_type-u.constant.type Z_TYPE(initialization-u.constant) !=
IS_NULL) {
+ zend_error(E_COMPILE_ERROR, Default
value for parameters with
%s type hint can only be %s or NULL,
zend_get_type_by_const(class_type-u.constant.type),
zend_get_type_by_const(class_type-u.constant.type));
That error says NULL is allowed for scalars, which I presume is wrong.
+ /* type forcing via cast */
+ case FORCE_BOOL:
+ case FORCE_STRING:
+ case FORCE_LONG:
+ case FORCE_DOUBLE:
+ if (op == ZEND_RECV_INIT) {
+ switch (Z_TYPE(initialization-u.constant)) {
+ case IS_ARRAY:
+ case IS_OBJECT:
+ case IS_RESOURCE:
+ zend_error(E_COMPILE_ERROR,
Default value for parameters with
a forced type of %s can only be a scalar,
zend_get_type_by_const(class_type-u.constant.type));
I think a default parameter of the wrong type must signify a
programmer error, so should be forbidden.
Index: Zend/zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.716.2.12.2.24.2.44
diff -u -p -a -d -u -r1.716.2.12.2.24.2.44 zend_execute.c
--- Zend/zend_execute.c 4 Jun 2009 18:20:42 - 1.716.2.12.2.24.2.44
+++ Zend/zend_execute.c 4 Jul 2009 17:20:50 -
@@ -506,13 +506,82 @@ static inline int zend_verify_arg_type(z
}
} else if (cur_arg_info-array_type_hint) {
if (!arg) {
- return zend_verify_arg_error(zf, arg_num, cur_arg_info,
be an
array, , none, TSRMLS_CC);
+ return zend_verify_arg_error(zf, arg_num, cur_arg_info,
be of the
type , zend_get_type_by_const(cur_arg_info-array_type_hint), none,
TSRMLS_CC);
}
- if (Z_TYPE_P(arg) != IS_ARRAY (Z_TYPE_P(arg) != IS_NULL ||
!cur_arg_info-allow_null)) {
- return zend_verify_arg_error(zf, arg_num, cur_arg_info,
be an
array, , zend_zval_type_name(arg), TSRMLS_CC);
+
+ /* existing type already matches the hint or forced type */
+ if (Z_TYPE_P(arg) == cur_arg_info-array_type_hint ||
Z_TYPE_P(arg)
== (cur_arg_info-array_type_hint ^ (17))) {
+ return 1;
+ }
+
+ /* NULL type give, check if parameter is optional */
I
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
It should be fine
Ilia Alshanetsky
On 2009-07-04, at 2:49 PM, Paul Biggar paul.big...@gmail.com wrote:
Hi Ilia,
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
wrote:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most
people
RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.109
diff -u -p -a -d -u -r1.647.2.27.2.41.2.109 zend_compile.c
--- Zend/zend_compile.c7 Jun 2009 15:46:51 -
1.647.2.27.2.41.2.109
+++ Zend/zend_compile.c4 Jul 2009 17:20:50 -
@@ -1511,10 +1514,9 @@ void zend_do_receive_arg(zend_uchar op,
zend_error(E_COMPILE_ERROR, Default value for
parameters with a
class type hint can only be NULL);
}
}
-} else {
-cur_arg_info-array_type_hint = 1;
-cur_arg_info-class_name = NULL;
-cur_arg_info-class_name_len = 0;
+break;
+
+case IS_ARRAY:
So, to signify an array type hint, we used to use 1, and we now use
IS_ARRAY, which is 4. I'm not 100% sure that's an ABI problem, but I
just wanted to check.
if (op == ZEND_RECV_INIT) {
if (Z_TYPE(initialization-u.constant) == IS_NULL ||
(Z_TYPE(initialization-u.constant) == IS_CONSTANT
!strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
cur_arg_info-allow_null = 1;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi!
RE your second patch, from http://ilia.ws/patch/type_hint_53_v2.txt
Some notes on this patch:
- I still think the matter of interfaces and inheritance should be dealt
with (and just comparing hints is not enough, it should be full
LSP-compliant check).
- It looks like you can't have class named string anymore, or at least
you can't use it in typehints (you can in 5.3). Same with all other type
names there.
- I see no reflection method that allows to get the type of the
parameter (as opposed to checking if the parameter belongs to a certain
type)
- The patch contains the check that the constant for an optional
parameter is not an object. AFAIK you can't have constant with object
type in PHP. Which also means initializer for any object type can only
be null.
- There seems to be no way to have default value with IS_NUMERIC
typecheck since the check
Z_TYPE(initialization-u.constant) != class_type-u.constant.type
will always fail for IS_NUMERIC - there's no zval carrying type
IS_NUMERIC. Same for IS_SCALAR.
- Also, I'm not sure what would happen there if I have:
function foo(numeric $param = CONSTANT)
and the value of CONSTANT may be not known in the compile-time. Looks
like right now it would just fail since CONSTANT has IS_CONSTANT type.
That would be confusing if you couldn't use constants for default values
with typehints.
- Shuouldn't this:
if (Z_TYPE_P(arg) == cur_arg_info-array_type_hint || Z_TYPE_P(arg) ==
(cur_arg_info-array_type_hint ^ (17))) {
be this:
if (Z_TYPE_P(arg) == (cur_arg_info-array_type_hint 0x7F)) {
this would be one check instead of two, and the type of argument zval
can't really be FORCE_*, can it?
- Are you sure with FORCE_* argument converting operation shouldn't be
convert_to_*_ex?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/2 Stanislav Malyshev s...@zend.com: It's not about the user input and security - it's about having different parts of your code working together through all possible changes. If you've got strict API you've got to make sure what you are sending to it would pass those strict checks, and would keep doing so through all changes done to the code. Hmm. Sounds like a programmers job you're describing there. I wonder if the split is between people coming to PHP from web design (JavaScript/Perl) and coming to PHP from other programming languages (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come from a Delphi's Object Pascal and Sage Retrieve 4GL (syntatically a mix of COBOL and Pascal). A big +1 from me to incorporate type hinting into PHP. I think calling this proposal type hinting just confuses the discussion. It's (optional) strict typing and it should be called so. Maybe this could be solved easier and made more acceptable to all sides if rather than calling it type hinting / (optional) strict typing it was called auto casting. A significant issue is what happens when the variables supplied are NOT of the appropriate type. I agree with Stanislav in that developers could end up with having to stuff their code with explicit type conversions. Inside the function/method, we are wanting to essentially force the inputs to match the requirements. So, rather than have the explicit type conversions being performed by users of the libraries, why not incorporate the conversions into the function/method declaration? If the data coming in is weakly typed, and we are wanting a specific type, we are going to cast it (currently). Casting is going to take place somewhere. Currently, you can use docblocks to suggest the type (no enforcement). If a user DOES read the docblocks and casts it, it doesn't actually help anyone as PHP is known to be weakly typed, so the library developer STILL has to do checks of some sort. But. If autocasting was available, users could RELY on the fact that PHP will use its built-in, well known and documented type-juggling logic to cast the supplied userland data to the libraries required type. This is now really utilising PHP's type-juggling to intelligently provide library developers with optional strict-typing. It incorporates type hinting, so a library user can do the casting if they want (I assume PHP does nothing for (string)1 or (int)4, etc.) Essentially auto casting would remove having to manually cast data at all. Regards, Richard. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/1 Ilia Alshanetsky i...@prohost.org:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
appear to think that this would be a good idea, but there is a reason why it
is not in PHP already. The main source of conflict appears to be that in
some cases typical type hinting is just too strict for PHP's typeless nature
(most people expect that 1 == 1, while int type hint would definitely
reject string 1). Personally, I disagree with that opinion, but I can
understand people who raise that issue. At work we've been using PHP 5.2
with type hinting for nearly 2 years now with great success, it makes code
much easier to read and understand and the security benefit of type hinting
is not to be under valued. In many cases type hinting can present a last
line of defense against unexpected input for numeric fields, which are
typically abused to do SQL injection.
I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type that
will allow any scalar data element.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.
My hope is that the latest changes will allow this to become a standard part
of PHP.
Brilliant stuff Ilia!
One thing I noticed in the patch is:
+ST_IN_SCRIPTING(string|binary|unicode) {
+ return T_STRING_HINT;
+}
which makes sense if we keep for PHP6 but doesn't for 5_3 which afaik
doesn't have (unicode) casting yet :) I think that's nitpicking I
agree and I just want to make sure that this doesn't become a
documentation issue for people who'd think you can hint using unicode
or even see article saying you can hint with unicode.
Makes sense for PHP6 though but since you merged your patch from 5.2 I
figured I could ask :)
Apart from that this is awesome and am I glad that we are not trying
to cast automatically!
+1
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi Ilia, Your patch doesn't support a null (or maybe it should be called unset) type check. Its uses would be rare, but I think it should be present for completeness. Thanks, Paul On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3. In recognition of a need for a more 'flexible' numeric type I've introduced (numeric) type hint that would allow bool/int/float data types as well as a string containing a numeric entity as identified by is_numeric_string(). For completion i've also added (scalar) data type that will allow any scalar data element. The patch is available here: http://ia.gd/patch/type_hint_53.txt It should be noted that this patch is fully compatible with opcode caches and and requires no changes on the part of an opcode cache such as APC to work. My hope is that the latest changes will allow this to become a standard part of PHP. Ilia Alshanetsky P.S. It should be noted that this is not the first idea for type hints, that credit goes to Hannes Magnusson who had posted a similar patch on the internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type hinting patch for PHP that is available on wiki.php.net. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi Ilia,
On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevs...@zend.com wrote:
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API this shouldn't happen in
5.3 branch. So maybe it's better to make it for 6.
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.40
diff -u -p -a -d -u -r1.316.2.8.2.12.2.40 zend_compile.h
--- Zend/zend_compile.h 5 Jun 2009 23:20:59 - 1.316.2.8.2.12.2.40
+++ Zend/zend_compile.h 1 Jul 2009 16:45:02 -
@@ -175,7 +175,7 @@ typedef struct _zend_arg_info {
zend_uint name_len;
const char *class_name;
zend_uint class_name_len;
- zend_bool array_type_hint;
+ zend_uint type_hint;
zend_bool allow_null;
zend_bool pass_by_reference;
zend_bool return_reference;
I think you could make this work for 5.3, if it used the old
zend_bool array_type_hint. A zend_bool is 8 bits, so that's plenty.
It would be a little bit messy, but I'm fairly confident it could be
made work.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Good point, this way API could remain the same.
On 3-Jul-09, at 9:31 AM, Paul Biggar wrote:
Hi Ilia,
On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevs...@zend.com
wrote:
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API this shouldn't
happen in
5.3 branch. So maybe it's better to make it for 6.
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.40
diff -u -p -a -d -u -r1.316.2.8.2.12.2.40 zend_compile.h
--- Zend/zend_compile.h 5 Jun 2009 23:20:59 - 1.316.2.8.2.12.2.40
+++ Zend/zend_compile.h 1 Jul 2009 16:45:02 -
@@ -175,7 +175,7 @@ typedef struct _zend_arg_info {
zend_uint name_len;
const char *class_name;
zend_uint class_name_len;
- zend_bool array_type_hint;
+ zend_uint type_hint;
zend_bool allow_null;
zend_bool pass_by_reference;
zend_bool return_reference;
I think you could make this work for 5.3, if it used the old
zend_bool array_type_hint. A zend_bool is 8 bits, so that's plenty.
It would be a little bit messy, but I'm fairly confident it could be
made work.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! I think you could make this work for 5.3, if it used the old zend_bool array_type_hint. A zend_bool is 8 bits, so that's plenty. It would be a little bit messy, but I'm fairly confident it could be made work. Unless the particular module would interpret everything that has non-zero array_type_hint as being typehinted to array, as it is now in 5.3.0. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! I wonder if the split is between people coming to PHP from web design (JavaScript/Perl) and coming to PHP from other programming languages (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come I've learned Java in about '96 and Perl around the same time. I wonder which box you'd want to put me in :) Maybe this could be solved easier and made more acceptable to all sides if rather than calling it type hinting / (optional) strict typing it was called auto casting. But as proposed it's not casting, unlike (string) - which is casting - it would just reject the variable that is not string, without any attempt to convert type. It's strict typing, just like C or Java do. So, rather than have the explicit type conversions being performed by users of the libraries, why not incorporate the conversions into the function/method declaration? That's what I was saying from the start. :) -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi, I'm a userland developer with limited C skills, and while I don't yet have an opinion on the whole type enforcing issue, aside from a fear of libraries abusing it, I'd like to propose a little change in the patch. Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to be thrown? I don't know whether InvalidArgumentException satisfies the semantics, but it's a step in that direction. On 7/1/2009 19:59, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3. In recognition of a need for a more 'flexible' numeric type I've introduced (numeric) type hint that would allow bool/int/float data types as well as a string containing a numeric entity as identified by is_numeric_string(). For completion i've also added (scalar) data type that will allow any scalar data element. The patch is available here: http://ia.gd/patch/type_hint_53.txt It should be noted that this patch is fully compatible with opcode caches and and requires no changes on the part of an opcode cache such as APC to work. My hope is that the latest changes will allow this to become a standard part of PHP. Ilia Alshanetsky P.S. It should be noted that this is not the first idea for type hints, that credit goes to Hannes Magnusson who had posted a similar patch on the internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type hinting patch for PHP that is available on wiki.php.net. -- Ionut G. Stan I'm under construction | http://igstan.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Thu, Jul 2, 2009 at 11:24, Ionut G. Stanionut.g.s...@gmail.com wrote:
Hi,
I'm a userland developer with limited C skills, and while I don't yet have
an
opinion on the whole type enforcing issue, aside from a fear of libraries
abusing
it, I'd like to propose a little change in the patch.
Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
be thrown? I don't know whether InvalidArgumentException satisfies the
semantics,
but it's a step in that direction.
?php
function throw_exception($errno, $errmsg) {
if (strpos($errmsg, Argument ) === 0) {
throw new InvalidArgumentException($errmsg, $errno);
}
return false;
}
set_error_handler(throw_exception, E_RECOVERABLE_ERROR);
function foo(array $arr) {}
foo(string);
Here you go.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On 7/2/2009 13:56, Hannes Magnusson wrote:
?php
function throw_exception($errno, $errmsg) {
if (strpos($errmsg, Argument ) === 0) {
throw new InvalidArgumentException($errmsg, $errno);
}
return false;
}
set_error_handler(throw_exception, E_RECOVERABLE_ERROR);
function foo(array $arr) {}
foo(string);
Actually, I'd use an exception class which extends from the builtin
ErrorException
class, but that's not the point. Anyway, probably Kalle Sommer Nielsen
is right,
and the way PHP already behaves in that regard should be kept. At least
for now.
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Ionut G. Stan wrote:
On 7/2/2009 13:56, Hannes Magnusson wrote:
?php
function throw_exception($errno, $errmsg) {
if (strpos($errmsg, Argument ) === 0) {
throw new InvalidArgumentException($errmsg, $errno);
}
return false;
}
set_error_handler(throw_exception, E_RECOVERABLE_ERROR);
function foo(array $arr) {}
foo(string);
Actually, I'd use an exception class which extends from the builtin
ErrorException
class, but that's not the point. Anyway, probably Kalle Sommer Nielsen
is right,
and the way PHP already behaves in that regard should be kept. At least
for now.
I think it should be E_WARNING with auto type juggling if bad data comes
through. This way it behaves as normal PHP code does without special
handling to mitigate a script failure. The log files will still alert
you to the problem, and if you really want an exception handler then you
still have that option.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/1 Stanislav Malyshev s...@zend.com: Hi! The patch is available here: http://ia.gd/patch/type_hint_53.txt Technical comment: as this patch changes binary API this shouldn't happen in 5.3 branch. So maybe it's better to make it for 6. As for the idea itself, it is obvious that many people like it, I would just note that it would produce a confusion for some people due to the fact that true, 1, 1.0, b'1' and '1' now become incompatible values and (once you start using typehints, of course) you'd have to explicitly convert them. That would lead people to stuff their code with explicit type conversions, which doesn't add to code cleanness. This also means that internal functions and user functions would behave differently with regard to type conversions. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Doesn't stuff their code with explicit type conversions actually mean perform appropriate validation and conversion on incoming data ? The majority of data that a program gets is either from a DB (and if ALL your columns are varchars, well, I give up and a xxx_fetch_row SHOULD cast to an appropriate type in my mind, but ...), from a config file (normally all strings), $_xxx (normally all strings). Internal values are inherently cast. How many people write ... $some_boolean = 1; // Set some_boolean flag to true. No, they write ... $some_boolean = true; // No need to document anything here as the code is pretty much speaking for itself. We are constantly told about GIGO and not accepting anything a user supplies as safe, so, with that in mind, you validate the incoming data (one way is to cast to the valid type and then check ranges, etc.) and from then on everything is in the appropriate type. PHP's type juggling is useful, without a doubt. But it seems to be limited to 2 areas. 1 - Casting to strings for output. 2 - Casting to boolean for equality testing. So they don't perform appropriate validation and conversion on incoming data, then you will end up with having to stuff their code with explicit type conversions. That's something I'm prepared to live with. So. A big +1 from me to incorporate type hinting into PHP. Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/2 Robert Cummings rob...@interjinn.com: Ionut G. Stan wrote: I think it should be E_WARNING with auto type juggling if bad data comes through. This way it behaves as normal PHP code does without special handling to mitigate a script failure. The log files will still alert you to the problem, and if you really want an exception handler then you still have that option. It should be an E_RECOVERABLE, as it would make most sense, the error is recoverable as it did not leave the engine in a state that it cannot continue from a technical standpoint. -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! Doesn't stuff their code with explicit type conversions actually mean perform appropriate validation and conversion on incoming data ? Sometimes it does, but in many cases it doesn't - since variables are not typed and types can be juggled, you'd have to take precautions even though you could be sure the value itself is sanitized. We are constantly told about GIGO and not accepting anything a user supplies as safe, so, with that in mind, you validate the incoming It's not about the user input and security - it's about having different parts of your code working together through all possible changes. If you've got strict API you've got to make sure what you are sending to it would pass those strict checks, and would keep doing so through all changes done to the code. A big +1 from me to incorporate type hinting into PHP. I think calling this proposal type hinting just confuses the discussion. It's (optional) strict typing and it should be called so. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Thu, Jul 02, 2009 at 09:59:43AM -0700, Stanislav Malyshev wrote: A big +1 from me to incorporate type hinting into PHP. I think calling this proposal type hinting just confuses the discussion. It's (optional) strict typing and it should be called so. +1 But first we must fix the current PHP manual that refers to it as type hinting: http://www.php.net/manual/en/language.oop5.typehinting.php -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Type hinting revisited for PHP 5.3
There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3. In recognition of a need for a more 'flexible' numeric type I've introduced (numeric) type hint that would allow bool/int/float data types as well as a string containing a numeric entity as identified by is_numeric_string(). For completion i've also added (scalar) data type that will allow any scalar data element. The patch is available here: http://ia.gd/patch/type_hint_53.txt It should be noted that this patch is fully compatible with opcode caches and and requires no changes on the part of an opcode cache such as APC to work. My hope is that the latest changes will allow this to become a standard part of PHP. Ilia Alshanetsky P.S. It should be noted that this is not the first idea for type hints, that credit goes to Hannes Magnusson who had posted a similar patch on the internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type hinting patch for PHP that is available on wiki.php.net. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. [snip] My hope is that the latest changes will allow this to become a standard part of PHP. +1 (+1000, actually :) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict ... Another desirable result of type hinting is that it would strengthen reflection ... one use of that would be automatic generation of WSDL files. This is something that I am currently struggling to do, not helped by the completely cr*p documentation of this - I am not talking about PHP documentation here by W3 other places :-( +1 to type hinting. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Ilia Alshanetsky schrieb: about introduction of type hinting to PHP About the introduction of scalar type hinting you mean? :-) I am all for this, but I think it would be wrong to add this in 5.3.X. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
I expect this would be a problem for folks who are relying on the fact that they can parse configuration files and web inputs purely as strings, yet numeric fields containing string representations of numbers will actually behave as numbers if called upon to do so. Speaking of which, when I'm in a hurry and large numbers (or negative numbers) are not dangerous in that particular context, I sometimes validate a numeric field like this: $x = $_REQUEST['x'] + 0; And then assume $x will be a number - perhaps an obnoxious number, maybe even a huge floating point number with an exponent, but a number. Is there a flaw in that reasoning that I'm not aware of? On Wed, Jul 1, 2009 at 1:15 PM, Alain Williamsa...@phcomp.co.uk wrote: On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict ... Another desirable result of type hinting is that it would strengthen reflection ... one use of that would be automatic generation of WSDL files. This is something that I am currently struggling to do, not helped by the completely cr*p documentation of this - I am not talking about PHP documentation here by W3 other places :-( +1 to type hinting. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
This is great! I've always wanted to see optional type hinting for PHP. On Wed, Jul 1, 2009 at 10:09 AM, Gwynne Raskind gwy...@darkrainfall.orgwrote: On Jul 1, 2009, at 12:59 PM, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict appears to be that in some cases typical type hinting is just too strict for PHP's typeless nature (most people expect that 1 == 1, while int type hint would definitely reject string 1). Personally, I disagree with that opinion, but I can understand people who raise that issue. At work we've been using PHP 5.2 with type hinting for nearly 2 years now with great success, it makes code much easier to read and understand and the security benefit of type hinting is not to be under valued. In many cases type hinting can present a last line of defense against unexpected input for numeric fields, which are typically abused to do SQL injection. [snip] My hope is that the latest changes will allow this to become a standard part of PHP. +1 (+1000, actually :) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
It also makes type analysis for potential compile time optimizations much easier. It reduces the unknowns that occure from functions! This is something that could be a big help with that. On Wed, Jul 1, 2009 at 10:15 AM, Alain Williams a...@phcomp.co.uk wrote: On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict ... Another desirable result of type hinting is that it would strengthen reflection ... one use of that would be automatic generation of WSDL files. This is something that I am currently struggling to do, not helped by the completely cr*p documentation of this - I am not talking about PHP documentation here by W3 other places :-( +1 to type hinting. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include http://www.ukuug.org/%0A#include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Yes 5.3.1 is definitely not the right time frame for a backwards incompatible change. On Wed, Jul 1, 2009 at 1:17 PM, Sebastian Bergmanns...@sebastian-bergmann.de wrote: Ilia Alshanetsky schrieb: about introduction of type hinting to PHP About the introduction of scalar type hinting you mean? :-) I am all for this, but I think it would be wrong to add this in 5.3.X. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org wrote:
I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type that
will allow any scalar data element.
I think this will go a long way to addressing people's concerns when
this came up previously.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
I presume the idea is that some people (if they so chose) would want
to type hint every parameter in their program. To facilitate this, I
might suggest a mixed hint (like in the docs), and a null hint
(though I'm not sure if it would be called null or unset or both).
Finally, I don't want to ruin this, but last time there was
disagreement over whether numbers should be coerced to the specified
types, or left alone. What does your patch do?
ie function x (int $x) { echo is_int ($x); } x (5);
Thanks,
Paul
It should be noted that this is not the first idea for type hints, that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
hinting patch for PHP that is available on wiki.php.net.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
+1000 * infinity plus one
On Jul 1, 2009, at 12:23 PM, Paul Biggar wrote:
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
wrote:
I've taken a few hours this morning to port my 5.2 type hinting
patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data
types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data
type that
will allow any scalar data element.
I think this will go a long way to addressing people's concerns when
this came up previously.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
I presume the idea is that some people (if they so chose) would want
to type hint every parameter in their program. To facilitate this, I
might suggest a mixed hint (like in the docs), and a null hint
(though I'm not sure if it would be called null or unset or both).
Finally, I don't want to ruin this, but last time there was
disagreement over whether numbers should be coerced to the specified
types, or left alone. What does your patch do?
ie function x (int $x) { echo is_int ($x); } x (5);
Thanks,
Paul
It should be noted that this is not the first idea for type hints,
that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a
type
hinting patch for PHP that is available on wiki.php.net.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! The patch is available here: http://ia.gd/patch/type_hint_53.txt Technical comment: as this patch changes binary API this shouldn't happen in 5.3 branch. So maybe it's better to make it for 6. As for the idea itself, it is obvious that many people like it, I would just note that it would produce a confusion for some people due to the fact that true, 1, 1.0, b'1' and '1' now become incompatible values and (once you start using typehints, of course) you'd have to explicitly convert them. That would lead people to stuff their code with explicit type conversions, which doesn't add to code cleanness. This also means that internal functions and user functions would behave differently with regard to type conversions. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetskyi...@prohost.org wrote: The patch is available here: http://ia.gd/patch/type_hint_53.txt It is missing minor build fix for ext/reflection, see http://pastebin.com/f50db9aa1 Other then that, I'm definitely +1 on this -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
As far as your point goes, numeric hint addresses it. Ilia Alshanetsky CIO/CSO Centah Inc. On 2009-07-01, at 2:07 PM, Stanislav Malyshev s...@zend.com wrote: Hi! The patch is available here: http://ia.gd/patch/type_hint_53.txt Technical comment: as this patch changes binary API this shouldn't happen in 5.3 branch. So maybe it's better to make it for 6. As for the idea itself, it is obvious that many people like it, I would just note that it would produce a confusion for some people due to the fact that true, 1, 1.0, b'1' and '1' now become incompatible values and (once you start using typehints, of course) you'd have to explicitly convert them. That would lead people to stuff their code with explicit type conversions, which doesn't add to code cleanness. This also means that internal functions and user functions would behave differently with regard to type conversions. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Tom, Type hinting is optional you don't have to use it. However, the numeric type I've added specifically addresses that point. Ilia Alshanetsky CIO/CSO Centah Inc. On 2009-07-01, at 1:22 PM, Tom Boutell t...@punkave.com wrote: I expect this would be a problem for folks who are relying on the fact that they can parse configuration files and web inputs purely as strings, yet numeric fields containing string representations of numbers will actually behave as numbers if called upon to do so. Speaking of which, when I'm in a hurry and large numbers (or negative numbers) are not dangerous in that particular context, I sometimes validate a numeric field like this: $x = $_REQUEST['x'] + 0; And then assume $x will be a number - perhaps an obnoxious number, maybe even a huge floating point number with an exponent, but a number. Is there a flaw in that reasoning that I'm not aware of? On Wed, Jul 1, 2009 at 1:15 PM, Alain Williamsa...@phcomp.co.uk wrote: On Wed, Jul 01, 2009 at 12:59:59PM -0400, Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. Most people appear to think that this would be a good idea, but there is a reason why it is not in PHP already. The main source of conflict ... Another desirable result of type hinting is that it would strengthen reflection ... one use of that would be automatic generation of WSDL files. This is something that I am currently struggling to do, not helped by the completely cr*p documentation of this - I am not talking about PHP documentation here by W3 other places :-( +1 to type hinting. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
If you use int type hit 1 will be rejected, but if use numeric type
hint it will be accepted.
Ilia Alshanetsky
On 2009-07-01, at 1:23 PM, Paul Biggar paul.big...@gmail.com wrote:
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
wrote:
I've taken a few hours this morning to port my 5.2 type hinting
patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data
types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data
type that
will allow any scalar data element.
I think this will go a long way to addressing people's concerns when
this came up previously.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
I presume the idea is that some people (if they so chose) would want
to type hint every parameter in their program. To facilitate this, I
might suggest a mixed hint (like in the docs), and a null hint
(though I'm not sure if it would be called null or unset or both).
Finally, I don't want to ruin this, but last time there was
disagreement over whether numbers should be coerced to the specified
types, or left alone. What does your patch do?
ie function x (int $x) { echo is_int ($x); } x (5);
Thanks,
Paul
It should be noted that this is not the first idea for type hints,
that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a
type
hinting patch for PHP that is available on wiki.php.net.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Although this sounds an extremely valid change, it breaks binary so
I'm against on 5.3.
Also, introducing type hints doesn't means that also core functions
should follow it? Because currently '1' is converted to true.
So in microtime for example... it should not support
microtime('true'), but microtime(true) only.
This is a change in zend_parse_parameters that automagically converts
to correct type. That means more logic that if this is applied to
userland, the same should be applied to internal functions.
Just my 0.02.
Cheers,
On Wed, Jul 1, 2009 at 3:12 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 18:59, Ilia Alshanetskyi...@prohost.org wrote:
The patch is available here: http://ia.gd/patch/type_hint_53.txt
It is missing minor build fix for ext/reflection, see
http://pastebin.com/f50db9aa1
Other then that, I'm definitely +1 on this
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! As far as your point goes, numeric hint addresses it. Numeric hint addresses one scenario only. It doesn't address conversions to strings or booleans, for example (even C allows you to use int as boolean! :). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 7:44 PM, Stanislav Malyshevs...@zend.com wrote: Hi! As far as your point goes, numeric hint addresses it. Numeric hint addresses one scenario only. It doesn't address conversions to strings or booleans, for example (even C allows you to use int as boolean! :). I agree. We won't be able to use an int type for something which should take an int. That might not matter in user code, but if we cannot actually type hint internals functions then its a problem. I think it should be a requirement that internals functions should be able to be type hinted using what the manual says. We don't need to be too strict on that, but if that manual says int, it should be hintable with int, and accept 1. My feeling is that scalars should be automatically coerced to the correct type, if it makes sense to do so. (ie reject non-numeric strings for ints). Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! I agree. We won't be able to use an int type for something which should take an int. That might not matter in user code, but if we cannot actually type hint internals functions then its a problem. Internal functions have types, however parameters of different types are usually converted, not rejected. My feeling is that scalars should be automatically coerced to the correct type, if it makes sense to do so. (ie reject non-numeric That (coercion) is what internal functions do, but not what the proposed patch does (except for numeric hint). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 8:04 PM, Stanislav Malyshevs...@zend.com wrote: I agree. We won't be able to use an int type for something which should take an int. That might not matter in user code, but if we cannot actually type hint internals functions then its a problem. Internal functions have types, however parameters of different types are usually converted, not rejected. Yes, rejection is bad. Coercion is good. (Silently accepting is bad). My feeling is that scalars should be automatically coerced to the correct type, if it makes sense to do so. (ie reject non-numeric That (coercion) is what internal functions do, but not what the proposed patch does (except for numeric hint). Right. I think we're arguing on the same side. I'm just saying that if the manual says 'int', we should be able to use int, and not be required to use 'numeric'. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. [..] My hope is that the latest changes will allow this to become a standard part of PHP. +1 [..] - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On 1 Jul 2009, at 18:59, Ilia Alshanetsky wrote:
The main source of conflict appears to be that in some cases typical
type hinting is just too strict for PHP's typeless nature (most
people expect that 1 == 1, while int type hint would definitely
reject string 1).
To be fair, this is really my compliant, but:
I think, for consistency, it should behaviour like
zend_parse_parameters, hence not being overly strict, and should set
the variable to it casted to the expected type. If it behaves
differently to zend_parse_parameters then it'll be annoying that
substr(), whose first parameter is a string, behaves differently to
function foobar(string $what) when passed an int, for example.
I'd expect:
function foo(string $bar) {
var_dump($bar);
}
foo(1234);
To output:
string(4) 1234
As this appears to be consistent with what internal functions that use
zend_parse_parameters do. I don't want PHP to become any more
inconsistent with itself than it already is.
--
Geoffrey Sneddon
http://gsnedders.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
C does not have booleans, they are emulated via smallint/tinyint. As far as your other message goes, this patch does nothing to affect how native functions handle args. Ilia Alshanetsky On 2009-07-01, at 2:44 PM, Stanislav Malyshev s...@zend.com wrote: Hi! As far as your point goes, numeric hint addresses it. Numeric hint addresses one scenario only. It doesn't address conversions to strings or booleans, for example (even C allows you to use int as boolean! :). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! C does not have booleans, they are emulated via smallint/tinyint. As far as your other message goes, this patch does nothing to affect how native functions handle args. Right. So we would have two APIs for types - one coercing (for internals) and one strict (for user functions), which would work in entirely different way. Is that good? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 22:29, Stanislav Malyshevs...@zend.com wrote:
Hi!
C does not have booleans, they are emulated via smallint/tinyint. As far
as your other message goes, this patch does nothing to affect how native
functions handle args.
Right. So we would have two APIs for types - one coercing (for internals)
and one strict (for user functions), which would work in entirely different
way. Is that good?
How is that different from what we have already?
Internally you type hint (arginfo) what you want, in userland you'll
be able to do that too (int $foo).
Internally you parse arguments (param parsing, casting), in userland
you do that already (function fo($var) {$var = (string)$var})
I don't understand what work entirely different you are talking
about. This is how PHP already works.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! Right. So we would have two APIs for types - one coercing (for internals) and one strict (for user functions), which would work in entirely different way. Is that good? How is that different from what we have already? Well, it's different in a way that right now we have typehints only for classes and arrays (which work the same internal and external) and conversions for internals and some places user code (which use the same logic, just in user code you can't apply them to function parameters automatically). With this patch, we won't have one logic anymore - we'd have two logics - one for typehinted functions (reject everything that doesn't match the type) and one for the rest of the language (try to coerce types). Two logics in one language is usually not good. Internally you type hint (arginfo) what you want, in userland you'll be able to do that too (int $foo). No, internal typehint doesn't work the way int typehint works with this patch. Internal typehint (zend_parse_parameters) do conversions, see zend_API.c. Only typehint that would resemble what internals do is numeric (well, and scalar, but it doesn't really have internal counterpart). I don't understand what work entirely different you are talking about. This is how PHP already works. No, that's exactly how PHP _doesn't_ work - there's always type coercion, not just matching of zval types. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, 1 Jul 2009, Ilia Alshanetsky wrote: I've taken a few hours this morning to port my 5.2 type hinting patch to 5.3. In recognition of a need for a more 'flexible' numeric type I've introduced (numeric) type hint that would allow bool/int/float data types as well as a string containing a numeric entity as identified by is_numeric_string(). For completion i've also added (scalar) data type that will allow any scalar data element. The patch is available here: http://ia.gd/patch/type_hint_53.txt +1 regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshevs...@zend.com wrote:
No, internal typehint doesn't work the way int typehint works with this
patch. Internal typehint (zend_parse_parameters) do conversions, see
You are wrong. Internal type hinting is done in the form of argument
information.
Those are identical to the userspace type hinting.
ZEND_BEGIN_ARG_INFO(arginfo_foo, 0)
ZEND_ARG_OBJ_INFO(0, MyClass, argumentName, 0)
ZEND_END_ARG_INFO();
is the same as the userspace form of:
function foo(MyClass $argumentName) {}
The current patch is missing a ZEND_ARG_STRING_INFO(0, argumentName,
0) which would be the same as
fnuction foo(string $argumentName){}
If that is the onlything you are worrying about then thats easily fixed.
zend_parse_parameters(... abcdefg)
is the same as
function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 10:02 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 22:50, Stanislav Malyshevs...@zend.com wrote:
No, internal typehint doesn't work the way int typehint works with this
patch. Internal typehint (zend_parse_parameters) do conversions, see
You are wrong. Internal type hinting is done in the form of argument
information.
Those are identical to the userspace type hinting.
ZEND_BEGIN_ARG_INFO(arginfo_foo, 0)
ZEND_ARG_OBJ_INFO(0, MyClass, argumentName, 0)
ZEND_END_ARG_INFO();
is the same as the userspace form of:
function foo(MyClass $argumentName) {}
The current patch is missing a ZEND_ARG_STRING_INFO(0, argumentName,
0) which would be the same as
fnuction foo(string $argumentName){}
If that is the onlything you are worrying about then thats easily fixed.
zend_parse_parameters(... abcdefg)
is the same as
function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}
So, what you're saying is, the patch already handles coercion? If
that's the case, then problem solved.
(But I didnt think it did.)
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote: So, what you're saying is, the patch already handles coercion? If that's the case, then problem solved. The patch offers scalar type _hinting_. Not type _casting_. Type hinting in PHP works very simply: If the value doesn't type-match the argument information (arginfo internally) then it will be rejected and E_RECOVERABLE_ERROR thrown. In most circumstances that error is fatal. However. If the user chooses then he can ignore that error (by creating his own error handler) and continue the execution. Type _hinting_ is in no way related to type _casting_. Furthermore, the patch introduces couple of new types, scalar and numeric. These are magic types and do value-to-real-type comparison. No type casting. The scalar type hint accepts strings, booleans, ints and floats. The numeric type hint accepts strings (that pass is_numeric()), booleans, ints and floats. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 10:23 PM, Hannes Magnussonhannes.magnus...@gmail.com wrote: On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote: So, what you're saying is, the patch already handles coercion? If that's the case, then problem solved. The patch offers scalar type _hinting_. Not type _casting_. Type hinting in PHP works very simply: If the value doesn't type-match the argument information (arginfo internally) then it will be rejected and E_RECOVERABLE_ERROR thrown. In most circumstances that error is fatal. However. If the user chooses then he can ignore that error (by creating his own error handler) and continue the execution. Type _hinting_ is in no way related to type _casting_. It should be. The current type hinting is for objects, which in PHP are strongly typed. We plan to extend it to scalars, which in PHP are weakly typed. Adding a strong type system for scalars goes against the rest of the language. As Stas said: With this patch, we won't have one logic anymore - we'd have two logics - one for typehinted functions (reject everything that doesn't match the type) and one for the rest of the language (try to coerce types). Two logics in one language is usually not good. PHP already has 2 type systems. I don't think that adding a 3rd one is complementary. Furthermore, the patch introduces couple of new types, scalar and numeric. These are magic types and do value-to-real-type comparison. No type casting. The scalar type hint accepts strings, booleans, ints and floats. The numeric type hint accepts strings (that pass is_numeric()), booleans, ints and floats. Yes. Therefore only the scalar and numeric types are useful. Nobody wants to use an 'int' hint that fails on numeric strings. Also, I don't know what happens for string hints when you pass an object with a __toString handler, but it should be allowed. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 23:36, Paul Biggarpaul.big...@gmail.com wrote:
On Wed, Jul 1, 2009 at 10:23 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote:
So, what you're saying is, the patch already handles coercion? If
that's the case, then problem solved.
The patch offers scalar type _hinting_. Not type _casting_.
Type hinting in PHP works very simply: If the value doesn't type-match
the argument information (arginfo internally) then it will be rejected
and E_RECOVERABLE_ERROR thrown.
In most circumstances that error is fatal. However. If the user
chooses then he can ignore that error (by creating his own error
handler) and continue the execution.
Type _hinting_ is in no way related to type _casting_.
It should be.
function foo(string $str, array $arr) {}
foo(false, foobar);
You are saying that the first argument should be casted, but not the second?
Or are you planning on breaking pretty much every single application using PHP5?
Furthermore, the patch introduces couple of new types, scalar and
numeric. These are magic types and do value-to-real-type
comparison. No type casting.
The scalar type hint accepts strings, booleans, ints and floats.
The numeric type hint accepts strings (that pass is_numeric()),
booleans, ints and floats.
Yes. Therefore only the scalar and numeric types are useful. Nobody
wants to use an 'int' hint that fails on numeric strings.
I do. I don't only deal with $_REQUEST stuff.
I don't have the resources to go the Y! route. I write bunch of stuff
in PHP. Real type hinting would help _alot_.
Also, I don't know what happens for string hints when you pass an
object with a __toString handler, but it should be allowed.
Apply the patch and try?
It would be neat if people would do a quick readthrough the patch
before arguing against it :)
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi!
You are wrong. Internal type hinting is done in the form of argument
information.
You are confusing arginfo's with zend_parse_parameters types. They work
differently (class typehints are strict, because there's no way to
convert classes from one type to another). These aren't even the same
types - all objects have the same internal type, IS_OBJECT, so it works
on entirely different level.
The current patch is missing a ZEND_ARG_STRING_INFO(0, argumentName,
0) which would be the same as
fnuction foo(string $argumentName){}
That doesn't exist and wouldn't exist for currently available functions
since making internal functions do that (strict type matching) would be
a huge code breakage.
zend_parse_parameters(... abcdefg)
is the same as
function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}
Now it is, but that's not the way typehints work in the proposed patch.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Hi! Type _hinting_ is in no way related to type _casting_. If you define it as such, there's no scalar type _hinting_ in PHP at all now. All engine works through _casting_. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
On Wed, Jul 1, 2009 at 10:53 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 23:36, Paul Biggarpaul.big...@gmail.com wrote:
On Wed, Jul 1, 2009 at 10:23 PM, Hannes
Magnussonhannes.magnus...@gmail.com wrote:
On Wed, Jul 1, 2009 at 23:07, Paul Biggarpaul.big...@gmail.com wrote:
So, what you're saying is, the patch already handles coercion? If
that's the case, then problem solved.
The patch offers scalar type _hinting_. Not type _casting_.
Type hinting in PHP works very simply: If the value doesn't type-match
the argument information (arginfo internally) then it will be rejected
and E_RECOVERABLE_ERROR thrown.
In most circumstances that error is fatal. However. If the user
chooses then he can ignore that error (by creating his own error
handler) and continue the execution.
Type _hinting_ is in no way related to type _casting_.
It should be.
function foo(string $str, array $arr) {}
foo(false, foobar);
You are saying that the first argument should be casted, but not the second?
Or are you planning on breaking pretty much every single application using
PHP5?
I'm sorry, I don't see what you're saying?
Yes. Therefore only the scalar and numeric types are useful. Nobody
wants to use an 'int' hint that fails on numeric strings.
I do. I don't only deal with $_REQUEST stuff.
I don't have the resources to go the Y! route. I write bunch of stuff
in PHP. Real type hinting would help _alot_.
My point is that type hints should be like what we've been using for
years in the docs.
There is obviously a tension here. People want two different features.
I'm not sure I see a way to reconcile that (unless you'd like 'strict
int' or 'is int'?)
Also, I don't know what happens for string hints when you pass an
object with a __toString handler, but it should be allowed.
Apply the patch and try?
It would be neat if people would do a quick readthrough the patch
before arguing against it :)
I did of course read the patch. I ask questions the way I do to avoid
confrontation, which is all too prevalent on this list.
I wanted to know what the code was intended to do, not what it does.
The patch wasnt clear without context, and it had no comments or
tests.
(FYI, I did a fairly detailed review of the type hinting patch last
year, which was ignored, so I'm reluctant to put the same effort in
here).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
