# [RFC - Discussion] Parameter Type Casting Hints - Thread: https://externals.io/message/58556 - Original archive: https://news-web.php.net/php.internals/58556 - Started by Anthony Ferrara on 2012-03-04T01:28:28+00:00 - Messages: 10 - 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 --- ## #58556 — Anthony Ferrara — 2012-03-04T01:28:28+00:00 URL: https://externals.io/message/58556#58556 Hey all, I've drafted an RFC for the Parameter type casting hint proposal that I posted to before. Attached to the RFC is a patch that's proposed for inclusion in core for functionality (it doesn't include news entries, or documentation, or any of the other steps that would be needed prior to commit). https://wiki.php.net/rfc/parameter_type_casting_hints Please provide feedback here on the implementation and RFC topics. Thanks, Anthony --- ## #58573 — Paul Dragoonis — 2012-03-04T13:57:23+00:00 URL: https://externals.io/message/58556#58573 · In reply to: #58556 Can you make sure that only scalar or array casts can be done? I wouldn't want people to put class typehints in there such as function foo( (SomeClass) $foo) - Paul. > Hey all, > > I've drafted an RFC for the Parameter type casting hint proposal that > I posted to before.  Attached to the RFC is a patch that's proposed > for inclusion in core for functionality (it doesn't include news > entries, or documentation, or any of the other steps that would be > needed prior to commit). > > https://wiki.php.net/rfc/parameter_type_casting_hints > > Please provide feedback here on the implementation and RFC topics. > > Thanks, > > Anthony --- ## #58575 — Anthony Ferrara — 2012-03-04T14:03:37+00:00 URL: https://externals.io/message/58556#58575 · In reply to: #58573 > Can you make sure that only scalar or array casts can be done? > > I wouldn't want people to put class typehints in there such as > function foo( (SomeClass) $foo) That's how it is implemented now. That'll generate a parse error... --- ## #58576 — Paul Dragoonis — 2012-03-04T14:06:46+00:00 URL: https://externals.io/message/58556#58576 · In reply to: #58575 Good. > > […] > > That's how it is implemented now.  That'll generate a parse error... --- ## #58582 — Lazare Inepologlou — 2012-03-04T16:26:10+00:00 URL: https://externals.io/message/58556#58582 · In reply to: #58573 > > I wouldn't want people to put class typehints in there such as > function foo( (SomeClass) $foo) > Why not? I would definitely like something like that, in the future. Here is an example: class DateTime { ... public function add( (DateInterval) $interval ) { ... } ... } $date = new DateTime; $date->add( 'P3D' ); // string to DateInterval casting $date->add( 3600 ); // int (seconds) to DateInterval casting Personally, I find this to be much closer to free type-juggling PHP style than the current implementation with type hints ( http://www.php.net/manual/en/datetime.add.php). [ Actually, I would prefer even type hints to work like this. Check if the passed argument if of the correct type and, if not, try to cast it. Failure to do so will lead to the `E_RECOVERABLE_ERROR` as today. ] Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/4 Paul Dragoonis > Can you make sure that only scalar or array casts can be done? > > I wouldn't want people to put class typehints in there such as > function foo( (SomeClass) $foo) > > - Paul. > > On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara > wrote: > > […] --- ## #58583 — Paul Dragoonis — 2012-03-04T16:34:04+00:00 URL: https://externals.io/message/58556#58583 · In reply to: #58582 Is (DateInterval) a valid cast currently in PHP ? If not, then we're not looking to add new fancy casting options, just give casting options on the simple existing ones. - Paul. > > […] > > > Why not? I would definitely like something like that, in the future. Here is > an example: > > class DateTime { >   ... >   public function add( (DateInterval) $interval ) { ... } >   ... > } > $date = new DateTime; > $date->add( 'P3D' ); // string to DateInterval casting > $date->add( 3600 );  // int (seconds) to DateInterval casting > > Personally, I find this to be much closer to free type-juggling PHP style > than the current implementation with type hints > (http://www.php.net/manual/en/datetime.add.php). > > [ Actually, I would prefer even type hints to work like this. Check if the > passed argument if of the correct type and, if not, try to cast it. Failure > to do so will lead to the `E_RECOVERABLE_ERROR` as today. ] > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > > 2012/3/4 Paul Dragoonis > > […] --- ## #58585 — Lazare Inepologlou — 2012-03-04T16:46:43+00:00 URL: https://externals.io/message/58556#58585 · In reply to: #58556 Anthony, just a tiny detail in your RCF: So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo > = “1” will generate an E_COMPILE_ERROR. > If null is going to be cast, (int)null is 0. So I don't think it should be a valid default value. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/4 Anthony Ferrara > Hey all, > > I've drafted an RFC for the Parameter type casting hint proposal that > I posted to before. Attached to the RFC is a patch that's proposed > for inclusion in core for functionality (it doesn't include news > entries, or documentation, or any of the other steps that would be > needed prior to commit). > > https://wiki.php.net/rfc/parameter_type_casting_hints > > Please provide feedback here on the implementation and RFC topics. > > Thanks, > > Anthony --- ## #58586 — Paul Dragoonis — 2012-03-04T16:50:19+00:00 URL: https://externals.io/message/58556#58586 · In reply to: #58585 It would make sense that the default value you're setting matches the zval.type of the casted value. You always want it to be an int, if you're doing (int) so setting it to a string or array would not make sense. - Paul. > Anthony, just a tiny detail in your RCF: > > So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo > > […] > > If null is going to be cast, (int)null is 0. So I don't think it should be > a valid default value. > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Anthony Ferrara > > > […] --- ## #58587 — Anthony Ferrara — 2012-03-04T17:17:17+00:00 URL: https://externals.io/message/58556#58587 · In reply to: #58585 > > > Anthony, just a tiny detail in your RCF: > > > […] $foo = “1” will generate an E_COMPILE_ERROR. > > > If null is going to be cast, (int)null is 0. So I don't think it should be a valid default value. Well, there were two reasons that I added null: first, for consistency with the existing type hints. Second, and more importantly, to allow checking if a parameter is specified. So without null, you couldn't tell the difference between an explicit 0 and an implicit (not specified) 0. This way, you can. I admit the use cases for that are rather slim, but a good portion of internal functions behave this way (substr comes to mind)... I think it is worth discussing further, as your point is indeed valid... > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Anthony Ferrara > > […] > > > Anthony, just a tiny detail in your RCF: > > So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo > > […] > > If null is going to be cast, (int)null is 0. So I don't think it should be > a valid default value. > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Anthony Ferrara > > > […] --- ## #58592 — Simon Schick — 2012-03-05T08:15:53+00:00 URL: https://externals.io/message/58556#58592 · In reply to: #58582 Hi, Lazare This is something not obvious, at least for me, and should be handled in the function itself. Here it would be better to update the function *add()* that you could also pass mixed and it will try to generate a *DateInterval *out of that or whatever. But that's another RFC. Type-juggling applies just to weak-types like string, int, float and boolean. I don't like to have this for resource, array or class excepted they are compatible to each other (like array and SplFixedArray, SplObjectStorage, ArrayIterator, ...) If you have to do something special to get the expected type (like creating a new object) type-juggling would not be the good-way to go. Bye Simon 2012/3/4 Lazare Inepologlou > > […] > function foo( (SomeClass) $foo) > > […] > > Why not? I would definitely like something like that, in the future. Here > is an example: > > class DateTime { > ... > public function add( (DateInterval) $interval ) { ... } > ... > } > $date = new DateTime; > $date->add( 'P3D' ); // string to DateInterval casting > $date->add( 3600 ); // int (seconds) to DateInterval casting > > Personally, I find this to be much closer to free type-juggling PHP style > than the current implementation with type hints ( > http://www.php.net/manual/en/datetime.add.php). > > [ Actually, I would prefer even type hints to work like this. Check if the > passed argument if of the correct type and, if not, try to cast it. Failure > to do so will lead to the `E_RECOVERABLE_ERROR` as today. ] > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Paul Dragoonis > > > […]