# [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters - Thread: https://externals.io/message/58800 - Original archive: https://news-web.php.net/php.internals/58800 - Started by Anthony Ferrara on 2012-03-09T02:32:12+00:00 - Messages: 46 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/58800.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #58800 — Anthony Ferrara — 2012-03-09T02:32:12+00:00 URL: https://externals.io/message/58800#58800 Hey all, As promised, I've created a POC patch to implement scalar type hints, the way that zend_parse_parameters handles hinting. First off, here's the patch: Directly apply-able without re2c: https://gist.github.com/2004623 Removing generated files (requires re2c to compile): https://gist.github.com/2004650 It's a POC, but it mostly works. There is one known issue: passing a class implementing __toString to a string hinted function will raise a segmentation fault. There's also an issue of not separating the argument on cast yielding to reference whether indicated or not, but that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in the cases where it would cast)... I'll work on cleaning it up, but I wanted to show the concept before investing too much work... So, basically, there are 4 new parameters: bool int float string The casting vs error rules are identical to zend_parse_parameters. So: function fooi(int $i) { var_dump($i); } fooi(1); // int(1) fooi(1.5); // int(1) fooi("1"); // int(1) fooi("1abc"); // int(1) + notice about non-well-formed numeric fooi("foo"); // `E_RECOVERABLE_ERROR` fooi(true); // int(1) fooi(array()); // `E_RECOVERABLE_ERROR` fooi($obj); // `E_RECOVERABLE_ERROR` function foob(bool $b) { var_dump($b); } foob(1); // bool(true) foob(1.5); // bool(true) foob("1"); // bool(true) foob("abc"); // bool(true) foob(true); // bool(true) foob(array()); // `E_RECOVERABLE_ERROR` foob($obj); // `E_RECOVERABLE_ERROR` function foos(string $s) { var_dump($s); foos(1); // string("1") foos(1.5); // string("1.5") foos("1"); // string("1") foos(true); // string("1") foos(array()); // `E_RECOVERABLE_ERROR` foos(new StdClass); // `E_RECOVERABLE_ERROR` foos($objImpl__toStringORcast_object); // string(result) Float works like int, so I won't list it out here... So, what do you think? Thanks, Anthony --- ## #58801 — Anthony Ferrara — 2012-03-09T02:58:01+00:00 URL: https://externals.io/message/58800#58801 · In reply to: #58800 Actually, it turns out the segfault and auto-reference bugs were easier than I thought to fix. I've updated both gists with the new code, and it looks to be running quite well... > Hey all, > > As promised, I've created a POC patch to implement scalar type hints, > the way that zend_parse_parameters handles hinting.  First off, here's > the patch: > > Directly apply-able without re2c: > https://gist.github.com/2004623 > > Removing generated files (requires re2c to compile): > https://gist.github.com/2004650 > > > It's a POC, but it mostly works.  There is one known issue: passing a > class implementing __toString to a string hinted function will raise a > segmentation fault.  There's also an issue of not separating the > argument on cast yielding to reference whether indicated or not, but > that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in > the cases where it would cast)... I'll work on cleaning it up, but I > wanted to show the concept before investing too much work... > > So, basically, there are 4 new parameters: > > bool > int > float > string > > The casting vs error rules are identical to zend_parse_parameters.  So: > > function fooi(int $i) { var_dump($i); } > > fooi(1); // int(1) > fooi(1.5); // int(1) > fooi("1"); // int(1) > fooi("1abc"); // int(1) + notice about non-well-formed numeric > fooi("foo"); // `E_RECOVERABLE_ERROR` > fooi(true); // int(1) > fooi(array()); // `E_RECOVERABLE_ERROR` > fooi($obj); // `E_RECOVERABLE_ERROR` > > function foob(bool $b) { var_dump($b); } > > foob(1); // bool(true) > foob(1.5); // bool(true) > foob("1"); // bool(true) > foob("abc"); // bool(true) > foob(true); // bool(true) > foob(array()); // `E_RECOVERABLE_ERROR` > foob($obj); // `E_RECOVERABLE_ERROR` > > function foos(string $s) { var_dump($s); > foos(1); // string("1") > foos(1.5); // string("1.5") > foos("1"); // string("1") > foos(true); // string("1") > foos(array()); // `E_RECOVERABLE_ERROR` > foos(new StdClass); // `E_RECOVERABLE_ERROR` > foos($objImpl__toStringORcast_object); // string(result) > > Float works like int, so I won't list it out here... > > > > So, what do you think? > > Thanks, > > Anthony --- ## #58802 — Anthony Ferrara — 2012-03-09T02:58:02+00:00 URL: https://externals.io/message/58800#58802 · In reply to: #58800 Actually, it turns out the segfault and auto-reference bugs were easier than I thought to fix. I've updated both gists with the new code, and it looks to be running quite well... > Hey all, > > As promised, I've created a POC patch to implement scalar type hints, > the way that zend_parse_parameters handles hinting.  First off, here's > the patch: > > Directly apply-able without re2c: > https://gist.github.com/2004623 > > Removing generated files (requires re2c to compile): > https://gist.github.com/2004650 > > > It's a POC, but it mostly works.  There is one known issue: passing a > class implementing __toString to a string hinted function will raise a > segmentation fault.  There's also an issue of not separating the > argument on cast yielding to reference whether indicated or not, but > that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in > the cases where it would cast)... I'll work on cleaning it up, but I > wanted to show the concept before investing too much work... > > So, basically, there are 4 new parameters: > > bool > int > float > string > > The casting vs error rules are identical to zend_parse_parameters.  So: > > function fooi(int $i) { var_dump($i); } > > fooi(1); // int(1) > fooi(1.5); // int(1) > fooi("1"); // int(1) > fooi("1abc"); // int(1) + notice about non-well-formed numeric > fooi("foo"); // `E_RECOVERABLE_ERROR` > fooi(true); // int(1) > fooi(array()); // `E_RECOVERABLE_ERROR` > fooi($obj); // `E_RECOVERABLE_ERROR` > > function foob(bool $b) { var_dump($b); } > > foob(1); // bool(true) > foob(1.5); // bool(true) > foob("1"); // bool(true) > foob("abc"); // bool(true) > foob(true); // bool(true) > foob(array()); // `E_RECOVERABLE_ERROR` > foob($obj); // `E_RECOVERABLE_ERROR` > > function foos(string $s) { var_dump($s); > foos(1); // string("1") > foos(1.5); // string("1.5") > foos("1"); // string("1") > foos(true); // string("1") > foos(array()); // `E_RECOVERABLE_ERROR` > foos(new StdClass); // `E_RECOVERABLE_ERROR` > foos($objImpl__toStringORcast_object); // string(result) > > Float works like int, so I won't list it out here... > > > > So, what do you think? > > Thanks, > > Anthony --- ## #58803 — Ilia Alshanetsky — 2012-03-09T02:58:52+00:00 URL: https://externals.io/message/58800#58803 · In reply to: #58800 Anthony, My concern with this type of patch is that what you are proposing are not really hints, they are forced casts. As such they modify the data potentially leading to data loss. > Hey all, > > As promised, I've created a POC patch to implement scalar type hints, > the way that zend_parse_parameters handles hinting.  First off, here's > the patch: > > Directly apply-able without re2c: > https://gist.github.com/2004623 > > Removing generated files (requires re2c to compile): > https://gist.github.com/2004650 > > > It's a POC, but it mostly works.  There is one known issue: passing a > class implementing __toString to a string hinted function will raise a > segmentation fault.  There's also an issue of not separating the > argument on cast yielding to reference whether indicated or not, but > that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in > the cases where it would cast)... I'll work on cleaning it up, but I > wanted to show the concept before investing too much work... > > So, basically, there are 4 new parameters: > > bool > int > float > string > > The casting vs error rules are identical to zend_parse_parameters.  So: > > function fooi(int $i) { var_dump($i); } > > fooi(1); // int(1) > fooi(1.5); // int(1) > fooi("1"); // int(1) > fooi("1abc"); // int(1) + notice about non-well-formed numeric > fooi("foo"); // `E_RECOVERABLE_ERROR` > fooi(true); // int(1) > fooi(array()); // `E_RECOVERABLE_ERROR` > fooi($obj); // `E_RECOVERABLE_ERROR` > > function foob(bool $b) { var_dump($b); } > > foob(1); // bool(true) > foob(1.5); // bool(true) > foob("1"); // bool(true) > foob("abc"); // bool(true) > foob(true); // bool(true) > foob(array()); // `E_RECOVERABLE_ERROR` > foob($obj); // `E_RECOVERABLE_ERROR` > > function foos(string $s) { var_dump($s); > foos(1); // string("1") > foos(1.5); // string("1.5") > foos("1"); // string("1") > foos(true); // string("1") > foos(array()); // `E_RECOVERABLE_ERROR` > foos(new StdClass); // `E_RECOVERABLE_ERROR` > foos($objImpl__toStringORcast_object); // string(result) > > Float works like int, so I won't list it out here... > > > > So, what do you think? > > Thanks, > > Anthony --- ## #58805 — Tjerk Anne Meesters — 2012-03-09T06:39:31+00:00 URL: https://externals.io/message/58800#58805 · In reply to: #58803 > Anthony, > > My concern with this type of patch is that what you are proposing are > not really hints, they are forced casts. As such they modify the data > potentially leading to data loss. > But at least it's consistent with "array" and class name qualifiers that php already has, regardless of what you want to call it, be it hints, casts, typing, etc. --- ## #58806 — Ryan McCue — 2012-03-09T06:52:17+00:00 URL: https://externals.io/message/58800#58806 · In reply to: #58800 Anthony Ferrara wrote: > So, what do you think? I am a big fan of this style. Accepting e.g. "1abc" as int(1) with a notice seems like a better solution than anything else. A full error would be too much towards strict typing (I wouldn't mind personally, but others do have a strong opinion on this, as we've seen). The only thing I'm not so crazy about is foob('abc') -> bool(true). I can live with it, but I don't particularly like it as far as the typing goes. Ilia Alshanetsky wrote: > My concern with this type of patch is that what you are proposing are > not really hints, they are forced casts. As such they modify the data > potentially leading to data loss. I disagree with Ilia on this, as the casts are only made if they can be converted properly, and give `E_RECOVERABLE_ERROR` instead. Anything that's going to have significant data loss is covered by that. Bottom line: I'd personally use this, while I certainly would not use the previous style (with `(int) $foo` e.g.). -- Ryan McCue Anthony, > > My concern with this type of patch is that what you are proposing are > not really hints, they are forced casts. As such they modify the data > potentially leading to data loss. This patch specifically tries to overcome this problem of the previous version. It will not accept input which will lead to a data loss on cast. The only exception is passing "123abc" to an int hint, which will cast to 123 and throw a notice. This is also my only point of critique: I'd prefer to be stricter here and go all the way to a recoverable fatal error. Nikita --- ## #58808 — Nikita Popov — 2012-03-09T08:10:56+00:00 URL: https://externals.io/message/58800#58808 · In reply to: #58800 > Hey all, > > As promised, I've created a POC patch to implement scalar type hints, > the way that zend_parse_parameters handles hinting.  First off, here's > the patch: Thanks for all the hard work you're putting into this :) > So, what do you think? This is the proposal I like most. It allows for some type juggling, but blocks off the ugly edge cases where dataloss would occur. Thinking in that direction I'd say that the casting rules are still too lax though: a) I'm not sure that we really want to accept '123abc' on an int cast with just a notice. In my eyes that is clearly malformed input, which should not be accepted. b) The bool cast rules also accept lots of input with dataloss. At least the fact that "abc" is considered a valid bool seems odd. Nikita --- ## #58809 — Simon Schick — 2012-03-09T08:36:16+00:00 URL: https://externals.io/message/58800#58809 · In reply to: #58808 Hi, all At first, many thanks to Anthony for writing the code! 2012/3/9 Anthony Ferrara > fooi(1.5); // int(1) Here an `E_NOTICE` would be a minimum as we are modifying the data. I'd like to see an `E_RECOVERABLE_ERROR` as well. You should use float-casting instead if you want to allow this as well. And this should be the only difference between int and float. (Float will of course also accept strings like "1.5") One more question I have to raise here ... is ".5" a valid float? Or do I have to change it to "0.5" to get it valid? 2012/3/9 Nikita Popov > > a) I'm not sure that we really want to accept '123abc' on an int cast > with just a notice. In my eyes that is clearly malformed input, which > should not be accepted. In my opinion '123abc' is not a valid integer as well. 2012/3/9 Nikita Popov > > b) The bool cast rules also accept lots of input with dataloss. At > least the fact that "abc" is considered a valid bool seems odd. I think all values that are not castable to an integer 0 or 1 should fail in Boolean. I pretty much like the rest. But as we are allowing classes implementing __toString() we should also think about updating the array type-cast - but that's another discussion that we can pick up later. Bye Simon --- ## #58810 — Arvids Godjuks — 2012-03-09T08:41:55+00:00 URL: https://externals.io/message/58800#58810 · In reply to: #58809 Overall good job. I would prefer it a little stricter like people already mention, but it's a step forward definitively with witch I'm totally fine to live with. --- ## #58811 — Gustavo Lopes — 2012-03-09T08:42:39+00:00 URL: https://externals.io/message/58800#58811 · In reply to: #58803 On Fri, 09 Mar 2012 03:58:52 +0100, Ilia Alshanetsky wrote: > My concern with this type of patch is that what you are proposing are > not really hints, they are forced casts. As such they modify the data > potentially leading to data loss. > Yes. Just like what happens with internal functions nowadays and this hasn't been particularly problematic. That said, I think we could move to a mild BC breaking change for php-next that would make zpp stricter (with or without user-land scalar type hinting/coercion). -- Gustavo Lopes --- ## #58812 — Christian Kaps — 2012-03-09T09:25:01+00:00 URL: https://externals.io/message/58800#58812 · In reply to: #58811 Am 09.03.2012 09:42, schrieb Gustavo Lopes: > That said, I think we could move to a mild BC breaking change for > php-next that would make zpp stricter (with or without user-land > scalar type hinting/coercion). A big +1 from me for this change. --- ## #58813 — Christian Kaps — 2012-03-09T09:25:47+00:00 URL: https://externals.io/message/58800#58813 · In reply to: #58810 Am 09.03.2012 09:41, schrieb Arvids Godjuks: > Overall good job. I would prefer it a little stricter like people > already > mention, but it's a step forward definitively with witch I'm totally > fine > to live with. Same from me. Good job. --- ## #58814 — Lazare Inepologlou — 2012-03-09T09:50:00+00:00 URL: https://externals.io/message/58800#58814 · In reply to: #58800 I like it. (Now, it would be nice to have another RFC about custom object casting to int, float and bool...) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 Anthony Ferrara > Hey all, > > As promised, I've created a POC patch to implement scalar type hints, > the way that zend_parse_parameters handles hinting. First off, here's > the patch: > > Directly apply-able without re2c: > https://gist.github.com/2004623 > > Removing generated files (requires re2c to compile): > https://gist.github.com/2004650 > > > It's a POC, but it mostly works. There is one known issue: passing a > class implementing __toString to a string hinted function will raise a > segmentation fault. There's also an issue of not separating the > argument on cast yielding to reference whether indicated or not, but > that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in > the cases where it would cast)... I'll work on cleaning it up, but I > wanted to show the concept before investing too much work... > > So, basically, there are 4 new parameters: > > bool > int > float > string > > The casting vs error rules are identical to zend_parse_parameters. So: > > function fooi(int $i) { var_dump($i); } > > fooi(1); // int(1) > fooi(1.5); // int(1) > fooi("1"); // int(1) > fooi("1abc"); // int(1) + notice about non-well-formed numeric > fooi("foo"); // `E_RECOVERABLE_ERROR` > fooi(true); // int(1) > fooi(array()); // `E_RECOVERABLE_ERROR` > fooi($obj); // `E_RECOVERABLE_ERROR` > > function foob(bool $b) { var_dump($b); } > > foob(1); // bool(true) > foob(1.5); // bool(true) > foob("1"); // bool(true) > foob("abc"); // bool(true) > foob(true); // bool(true) > foob(array()); // `E_RECOVERABLE_ERROR` > foob($obj); // `E_RECOVERABLE_ERROR` > > function foos(string $s) { var_dump($s); > foos(1); // string("1") > foos(1.5); // string("1.5") > foos("1"); // string("1") > foos(true); // string("1") > foos(array()); // `E_RECOVERABLE_ERROR` > foos(new StdClass); // `E_RECOVERABLE_ERROR` > foos($objImpl__toStringORcast_object); // string(result) > > Float works like int, so I won't list it out here... > > > > So, what do you think? > > Thanks, > > Anthony --- ## #58817 — Anthony Ferrara — 2012-03-09T12:37:05+00:00 URL: https://externals.io/message/58800#58817 · In reply to: #58814 > (Now, it would be nice to have another RFC about custom object casting to > int, float and bool...) You mean like https://wiki.php.net/rfc/object_cast_to_types which is still in draft? Note that __toBool would be problematic, since it would be called if the object was used in an if statement, which could yield some very strange results if it returned false (it would break the existing semantics about how we can use if statements to determine if the type is populated)... Anthony --- ## #58818 — John Crenshaw — 2012-03-09T13:21:24+00:00 URL: https://externals.io/message/58800#58818 · In reply to: #58817 > > […] > > You mean like https://wiki.php.net/rfc/object_cast_to_types which is still in draft? > > Note that __toBool would be problematic, since it would be called if the object was used in an if statement, which could yield some very strange results if it returned false (it would break the existing semantics about how we can use if statements to determine if the type is populated)... > > Anthony And yet, __toBool probably sits right next to __toArray in terms of the level of usefulness (maybe even beats it.) isset() can always be used to determine whether something was ACTUALLY set to a non-null value, and to some extent there is already a semantic problem anyway since things like if("0") resolve to false. John Crenshaw Priacta, Inc. --- ## #58819 — Anthony Ferrara — 2012-03-09T13:45:03+00:00 URL: https://externals.io/message/58800#58819 · In reply to: #58818 John, > And yet, __toBool probably sits right next to __toArray in terms of the level of usefulness (maybe even beats it.) isset() can always be used to determine whether something was ACTUALLY set to a non-null value, and to some extent there is already a semantic problem anyway since things like if("0") resolve to false. The original proposal was to include toBool functionality. Stas was one who strongly opposed it which is one of the reasons that I removed it. However, if a convincing case can be made to add it in, and there's enough buy in, I would love to see it added. My issue is that I don't want the whole proposal rejected because of that one method... But that's what a RFC process is for, so let's get discussing... Thanks, Anthony --- ## #58820 — Lazare Inepologlou — 2012-03-09T13:54:08+00:00 URL: https://externals.io/message/58800#58820 · In reply to: #58817 Yes, like that, only better. Since automatic type casting is central in PHP, as this is evident after all this discussion, I believe that it should be better supported. There are two thinks that I would like to see here: 1. No more magic methods, please. 2. It should cover (eventually) casting to and from any type. :-) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 Anthony Ferrara > > […] > > You mean like https://wiki.php.net/rfc/object_cast_to_types which is > still in draft? > > Note that __toBool would be problematic, since it would be called if > the object was used in an if statement, which could yield some very > strange results if it returned false (it would break the existing > semantics about how we can use if statements to determine if the type > is populated)... > > Anthony --- ## #58821 — Simon Schick — 2012-03-09T14:27:28+00:00 URL: https://externals.io/message/58800#58821 · In reply to: #58820 2012/3/9 Lazare Inepologlou > > Yes, like that, only better. Since automatic type casting is central in > PHP, as this is evident after all this discussion, I believe that it > should > be better supported. There are two thinks that I would like to see here: > > 1. No more magic methods, please. > 2. It should cover (eventually) casting to and from any type. > > :-) > > Lazare INEPOLOGLOU > Ingénieur Logiciel > Hi, Lazare As you mentioned it in another thread, I like the idea of C# you described ... Draw a line between explicit and implicit casting. What the current idea would be is an implicit casting (as I understood it right). Let me just repeat your examples: 2012/3/7 Lazare Inepologlou > function test_float( float test ) { ... } > test_float( 1.0 ); // ok > test_float( 1 ); // implicit int to float cast, ok > > function test_array( array test ) { ... } > test_array( array() ); // ok > test_array( 1 ); // no implicit int to array cast, error! > test_array( (array)1 ); // explicit int to array cast, ok An explicit type-cast should be always possible and try to get the very last bit of useful information out of the given bunch. Here it makes sense to have magic functions for integer, float, string etc. But as we're here talking about an implicit casting when passing a class to a function, I don't like the idea of calling the magic-functions if you paste a class in here as it changes the content of the variable. This won't make it easy passing a variable as reference. If you just switch to another type, you can afterwards do whatever you was able to do before. Bye Simon --- ## #58822 — Anthony Ferrara — 2012-03-09T14:34:17+00:00 URL: https://externals.io/message/58800#58822 · In reply to: #58820 Lazare, > Yes, like that, only better. Since automatic type casting is central in PHP, > as this is evident after all this discussion, I believe that it should be > better supported. There are two thinks that I would like to see here: > > 1. No more magic methods, please. Any particular reason? If the magic is useful, why not add the ability? I'm not saying we should get to python level with the shear number of magic methods, but to artificially limit when useful behavior can be added... I'm not so sure... > 2. It should cover (eventually) casting to and from any type. This doesn't? What other types (except from other classes) would you like to see (or could we do besides resource and null)??? Anthony --- ## #58823 — Lazare Inepologlou — 2012-03-09T15:04:31+00:00 URL: https://externals.io/message/58800#58823 · In reply to: #58822 > What other types (except from other classes)... I was talking about other classes... Of course, this does not have to be implemented right now, but the syntax should not close the door for something like that in the future. > If the magic is useful, why not add the ability? Because it is ugly and limited. All the resent discussion resulted to the fact that type casting is one of the central features of PHP that we cannot live without. So I think that the mechanism to expand type casting should be promoted, even with some special new syntax. :-) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 Anthony Ferrara > Lazare, > > On Fri, Mar 9, 2012 at 8:54 AM, Lazare Inepologlou > wrote: > > […] > PHP, > > […] > > Any particular reason? If the magic is useful, why not add the > ability? I'm not saying we should get to python level with the shear > number of magic methods, but to artificially limit when useful > behavior can be added... I'm not so sure... > > > […] > > This doesn't? What other types (except from other classes) would you > like to see (or could we do besides resource and null)??? > > Anthony --- ## #58824 — Lazare Inepologlou — 2012-03-09T15:20:14+00:00 URL: https://externals.io/message/58800#58824 · In reply to: #58821 > What the current idea would be is an implicit casting (as I understood it right). Yes, exactly. > This won't make it easy passing a variable as reference. Type casting combined with passing by reference is problematic in many ways. Just an example: fuction foo( string & $buffer) { ... } foo( $my_buffer ); Here, $my_buffer has just been declared, so it is null. Should this be an error? I don't know! So, I think that that passing by reference should not be (immediately) supported. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 Simon Schick > 2012/3/9 Lazare Inepologlou > > […] > > Hi, Lazare > > As you mentioned it in another thread, I like the idea of C# you described > ... > Draw a line between explicit and implicit casting. > > What the current idea would be is an implicit casting (as I understood > it right). > Let me just repeat your examples: > > 2012/3/7 Lazare Inepologlou > > […] > > An explicit type-cast should be always possible and try to get the > very last bit of useful information out of the given bunch. Here it > makes sense to have magic functions for integer, float, string etc. > > But as we're here talking about an implicit casting when passing a > class to a function, I don't like the idea of calling the > magic-functions if you paste a class in here as it changes the content > of the variable. This won't make it easy passing a variable as > reference. If you just switch to another type, you can afterwards do > whatever you was able to do before. > > Bye > Simon --- ## #58825 — Simon Schick — 2012-03-09T17:45:19+00:00 URL: https://externals.io/message/58800#58825 · In reply to: #58824 2012/3/9 Lazare Inepologlou > > Type casting combined with passing by reference is problematic in many ways. Just an example: > > fuction foo( string & $buffer) { ... } > foo( $my_buffer ); > > Here, $my_buffer has just been declared, so it is null. Should this be an error? I don't know! So, I think that that passing by reference should not be (immediately) supported. > Hi, Lazare This should at least throw an `E_NOTICE` :) And also an error as `NULL` is not allowed here. Let me modify your example: fuction foo( string & $buffer = NULL) { ... } foo( $my_buffer ); This would only raise the `E_NOTICE` because the variable has not been declared. Or would you say that `NULL` is equal with an empty string (talking about implicit casting)? I would not like that, but if, don't let it be (int)0 or (bool)false as well. Bye Simon --- ## #58826 — John Crenshaw — 2012-03-09T22:58:19+00:00 URL: https://externals.io/message/58800#58826 · In reply to: #58825 From: Simon Schick [mailto:simonsimcity@googlemail.com] > > 2012/3/9 Lazare Inepologlou > > […] > > Hi, Lazare > > This should at least throw an `E_NOTICE` :) And also an error as `NULL` is not allowed here. > > Let me modify your example: > > fuction foo( string & $buffer = NULL) { ... } foo( $my_buffer ); > > This would only raise the `E_NOTICE` because the variable has not been declared. > Or would you say that `NULL` is equal with an empty string (talking about implicit casting)? I would not like that, but if, don't let it be (int)0 or (bool)false as well. > > Bye > Simon The reason you have to validate the input type in this case is because even though it is a reference, we don't ACTALLY know that it isn't supposed to contain an input (even though that would be against all sane rules most of the time). I'm not attached to this idea at all, but I thought I'd throw it out and see if anyone can think of a problem with it; what if we added extra out and inout hints for references? // So this would give no error at all. Parameter is anticipated to be for output. Just silently change the type and don't warn on anything. fuction foo( out string & $buffer) { ... } foo( $my_buffer ); // This WOULD give an error, because the parameter is also an input parameter: fuction foo( inout string & $buffer = NULL) { ... } foo( $my_buffer ); // In any case no errors on these: fuction foo( inout string & $buffer = NULL) { ... } foo( (string)$my_buffer ); fuction foo( string & $buffer = NULL) { ... } foo( (string)$my_buffer ); If we assumed that all references were out unless stated otherwise we could avoid reserving an "out" keyword, and only add "inout", which is unlikely to conflict with stuff. Like I said, no attachment to this at all. My gut tells me I may have missed something really stupid here. Just brainstorming. John Crenshaw Priacta, Inc. --- ## #58827 — Lazare Inepologlou — 2012-03-09T23:32:10+00:00 URL: https://externals.io/message/58800#58827 · In reply to: #58826 > what if we added extra out and inout hints for references? With the danger of becoming boring, I have to say that C# also support "ref" and "out" arguments... Are we reinventing the wheel here? To be honest, this is going too far. Can we have the basics first? Passing by reference is a corner case, at least for PHP. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/9 John Crenshaw > From: Simon Schick [mailto:simonsimcity@googlemail.com] > > […] > ways. Just an example: > > […] > an error? I don't know! So, I think that that passing by reference should > not be (immediately) supported. > > […] > not allowed here. > > […] > declared. > > […] > implicit casting)? I would not like that, but if, don't let it be (int)0 or > (bool)false as well. > > […] > > The reason you have to validate the input type in this case is because > even though it is a reference, we don't ACTALLY know that it isn't supposed > to contain an input (even though that would be against all sane rules most > of the time). > > I'm not attached to this idea at all, but I thought I'd throw it out and > see if anyone can think of a problem with it; what if we added extra out > and inout hints for references? > > // So this would give no error at all. Parameter is anticipated to be for > output. Just silently change the type and don't warn on anything. > fuction foo( out string & $buffer) { ... } foo( $my_buffer ); > > // This WOULD give an error, because the parameter is also an input > parameter: > fuction foo( inout string & $buffer = NULL) { ... } foo( $my_buffer ); > > // In any case no errors on these: > fuction foo( inout string & $buffer = NULL) { ... } foo( > (string)$my_buffer ); > fuction foo( string & $buffer = NULL) { ... } foo( (string)$my_buffer ); > > If we assumed that all references were out unless stated otherwise we > could avoid reserving an "out" keyword, and only add "inout", which is > unlikely to conflict with stuff. > > Like I said, no attachment to this at all. My gut tells me I may have > missed something really stupid here. Just brainstorming. > > John Crenshaw > Priacta, Inc. --- Next page: https://externals.io/message/58800.md?page=2