# Return type hints - Thread: https://externals.io/message/36827 - Original archive: https://news-web.php.net/php.internals/36827 - Started by Felipe Pena on 2008-04-07T03:41:35+00:00 - Messages: 42 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/36827.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 --- ## #36827 — Felipe Pena — 2008-04-07T03:41:35+00:00 URL: https://externals.io/message/36827#36827 Hello ladies and gentlemen, I made a patch that implements an experimental return type hint, therefore we need discuss much about this yet, right? :) My idea uses (php-type) and +className as notation, see below. - PHP types function (string) foo(...) { } // Unicode string too function (object) foo(...) { } // Strict function (array) foo(...) { } // Strict function (bool) foo(...) { } // Strict function (int) foo(...) { } // Accepts numeric string function (double) foo(...) { } // Accepts numeric string :: Question --------------------------- - Add (resource), (unicode), (void) ? | --------------------------------------- - Userland types (like actual parameter type-hint) function +className foo(...) { } function +interfaceName foo(...) { } // Uses the class/interface 'int', not the type function +int foo(...) { } :: Question ---------------------------- - Weird syntax? | ---------------------------------------- :: Examples ------------------------------------------------ interface Itest { } class bar implements Itest { } class foo extends bar { } class test { static public function +Itest testing($instance) { return $instance; } } test::testing(new bar); test::testing(new foo); test::testing(new stdclass); // Error! // Catchable fatal error: The returned value must implement interface Itest ----------------------------------------- class foo { public function +self getInstance() { return $this; } } $test = new foo; var_dump($test->getInstance()); // OK! object(foo)#1 (0) { } Finally, it's nice or poor syntax? What must be improved/changed? (All?) Patch: http://felipe.ath.cx/diff/return_type_hint.diff Tests: http://felipe.ath.cx/diff/tests/ -- Regards, Felipe Pena. --- ## #36828 — crrodriguez@suse.de — 2008-04-07T04:11:24+00:00 URL: https://externals.io/message/36827#36828 · In reply to: #36827 Felipe Pena escribió: > Hello ladies and gentlemen, > > I made a patch that implements an experimental return type hint, > therefore we need discuss much about this yet, right? :) Thanks for raising this issue !! > function (int) foo(...) { } // Accepts numeric string > function (double) foo(...) { } // Accepts numeric string hrmmm.. nope. neither double nor int should accept numeric string.. > > > :: Question --------------------------- > - Add (resource), (unicode), (void) ? | > --------------------------------------- yes !! > :: Question ---------------------------- > - Weird syntax? | > ---------------------------------------- Yes, not intuitive at all... > What must be improved/changed? (All?) Dunno, Have not tested the patch yet, but will :) Thanks. -- “If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --- ## #36829 — Mike Lively — 2008-04-07T04:57:38+00:00 URL: https://externals.io/message/36827#36829 · In reply to: #36827 > - PHP types > > function (string) foo(...) { } // Unicode string too > function (object) foo(...) { } // Strict > function (array) foo(...) { } // Strict > function (bool) foo(...) { } // Strict > function (int) foo(...) { } // Accepts numeric string > function (double) foo(...) { } // Accepts numeric string If there ever were return type hinting in PHP I don't think it would be wise to support PHP Types unless parameter hints were changed to support them. It's just inconsistent. > :: Question ---------------------------- > - Weird syntax? | > ---------------------------------------- > Yes, is there any reason why any special characters are needed? --- ## #36832 — Timothy Chandler — 2008-04-07T05:48:50+00:00 URL: https://externals.io/message/36827#36832 · In reply to: #36827 I guess I should say it before anyone else does... "It's not the PHP way" - Timothy Chandler Simple Site Solutions Felipe Pena wrote: > Hello ladies and gentlemen, > > I made a patch that implements an experimental return type hint, > therefore we need discuss much about this yet, right? :) > > My idea uses (php-type) and +className as notation, see below. > > - PHP types > > function (string) foo(...) { } // Unicode string too > function (object) foo(...) { } // Strict > function (array) foo(...) { } // Strict > function (bool) foo(...) { } // Strict > function (int) foo(...) { } // Accepts numeric string > function (double) foo(...) { } // Accepts numeric string > > > :: Question --------------------------- > - Add (resource), (unicode), (void) ? | > --------------------------------------- > > - Userland types (like actual parameter type-hint) > > function +className foo(...) { } > function +interfaceName foo(...) { } > // Uses the class/interface 'int', not the type > function +int foo(...) { } > > :: Question ---------------------------- > - Weird syntax? | > ---------------------------------------- > > :: Examples ------------------------------------------------ > > interface Itest { } > class bar implements Itest { } > class foo extends bar { } > > class test { > static public function +Itest testing($instance) { > return $instance; > } > } > > test::testing(new bar); > test::testing(new foo); > test::testing(new stdclass); // Error! > // Catchable fatal error: The returned value must implement interface > Itest > > ----------------------------------------- > > class foo { > public function +self getInstance() { > return $this; > } > } > > $test = new foo; > var_dump($test->getInstance()); // OK! > > object(foo)#1 (0) { > } > > > Finally, it's nice or poor syntax? > > What must be improved/changed? (All?) > > > Patch: http://felipe.ath.cx/diff/return_type_hint.diff > Tests: http://felipe.ath.cx/diff/tests/ --- ## #36836 — Richard Quadling — 2008-04-07T10:00:13+00:00 URL: https://externals.io/message/36827#36836 · In reply to: #36832 > I guess I should say it before anyone else does... > > "It's not the PHP way" > > - Timothy Chandler > Simple Site Solutions And before PHP6 neither was native Unicode. And before PHP5 neither was a lot of the cool features of OOP (yeah PHP4 had it but in a different way). The PHP way is, at best, how thing were done until enough people wanted it and it is now how things are done. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #36837 — Felipe Pena — 2008-04-07T11:07:31+00:00 URL: https://externals.io/message/36827#36837 · In reply to: #36832 Em Seg, 2008-04-07 às 15:48 +1000, Timothy Chandler escreveu: > I guess I should say it before anyone else does... > > "It's not the PHP way" > Do you mean the way that i initially suggest? Anyway return type hints (probably)? will implemented, at least it was accepted in 'Minutes PHP Developers Meeting'. As far as i know, just wasn't decided the syntax. > - Timothy Chandler > Simple Site Solutions > > Felipe Pena wrote: > > […] > -- Regards, Felipe Pena. --- ## #36838 — Felipe Pena — 2008-04-07T12:28:16+00:00 URL: https://externals.io/message/36827#36838 Em Seg, 2008-04-07 às 01:32 -0700, kalle@zesix.com escreveu: > > […] > > The syntax with the type casting seems abit weird as I've wrote above, I > would suggest perhaps making each datatype name a reserved keyword, eg. > int, integer, bool, bolean ect. I really tried avoid this. This is the reason for two notations. -- Regards, Felipe Pena. --- ## #36841 — troels knak-nielsen — 2008-04-07T13:06:09+00:00 URL: https://externals.io/message/36827#36841 · In reply to: #36838 > class test { > static public function +Itest testing($instance) { > return $instance; > } > } A more sane syntax, might be something like: class test { static function testing($instance) : Itest { return $instance; } } -- troels --- ## #36842 — Jarismar Chaves da Silva — 2008-04-07T13:15:00+00:00 URL: https://externals.io/message/36827#36842 · In reply to: #36841 Or something like this would be nice too, please avoid using + or (). class test { public static Itest function testing($instance) { return $instance; } } troels knak-nielsen wrote: > > > > […] > > A more sane syntax, might be something like: > > class test { > static function testing($instance) : Itest { > return $instance; > } > } > > -- > troels > > -- *Jarismar Chaves da Silva* --- ## #36843 — Felipe Pena — 2008-04-07T13:36:39+00:00 URL: https://externals.io/message/36827#36843 · In reply to: #36842 Hello, Em Seg, 2008-04-07 às 10:15 -0300, Jarismar Chaves da Silva escreveu: > Or something like this would be nice too, please avoid using + > or (). > > class test { > public static Itest function testing($instance) { > return $instance; > } > } > > troels knak-nielsen wrote: > > […] > -- > Jarismar Chaves da Silva As i said previously: > I really tried avoid this. > This is the reason for two notations. Actually 'integer', 'double', 'string', etc are allowed in function, class and interface names. Using only 1 notation, we would have that make them keywords. -- Regards, Felipe Pena. --- ## #36844 — Derick Rethans — 2008-04-07T13:44:45+00:00 URL: https://externals.io/message/36827#36844 · In reply to: #36829 > > > > […] > > > If there ever were return type hinting in PHP I don't think it would be wise > to support PHP Types unless parameter hints were changed to support them. > It's just inconsistent. Right, this shouldn't even be on the agenda before we have scalar type hints. So, perhaps you can make a patch for that first Felipe? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #36845 — Felipe Pena — 2008-04-07T13:57:56+00:00 URL: https://externals.io/message/36827#36845 · In reply to: #36844 Em Seg, 2008-04-07 às 15:44 +0200, Derick Rethans escreveu: > > > > […] > > Right, this shouldn't even be on the agenda before we have scalar type > hints. So, perhaps you can make a patch for that first Felipe? I don't thought this before! Sure, i'll try provide a patch. Thanks. -- Regards, Felipe Pena. --- ## #36846 — Sam Barrow — 2008-04-07T14:02:22+00:00 URL: https://externals.io/message/36827#36846 · In reply to: #36845 I have a scalar type hinting patch on my blog at www.sambarrow.com > > I don't thought this before! > Sure, i'll try provide a patch. --- ## #36847 — Ben Ramsey — 2008-04-07T15:03:30+00:00 URL: https://externals.io/message/36827#36847 · In reply to: #36842 > Or something like this would be nice too, please avoid using + or > (). > > class test { > public static Itest function testing($instance) { > return $instance; > } > } I think this is the most intuitive approach. However, this means that regular function declarations would be like: Itest function testing($instance) { return $instance; } Would this present a problem? -- Ben Ramsey http://benramsey.com/ --- ## #36851 — Christian Schneider — 2008-04-07T16:49:01+00:00 URL: https://externals.io/message/36827#36851 · In reply to: #36845 Felipe Pena wrote: > > […] > > I don't thought this before! > Sure, i'll try provide a patch. Just so this side was mentioned once again too: There are people who consider type hints and especially scalar type hints A Bad Thing(tm) as it is contrary to the PHP strength of dynamic typing and automatic type conversion. I just ran into this (IMHO unnecessary) limitation with array_reduce: Why should it only reduce to an int? Why not a string or an array? I plan on submitting a patch for PHP 6 to allow other types too. - Chris --- ## #36852 — Stanislav Malyshev — 2008-04-07T16:57:58+00:00 URL: https://externals.io/message/36827#36852 · In reply to: #36851 Hi! > I just ran into this (IMHO unnecessary) limitation with array_reduce: > Why should it only reduce to an int? Why not a string or an array? I > plan on submitting a patch for PHP 6 to allow other types too. I'm not sure I understand - how array_reduce is related to having type hints? You could make array_reduce to do additional things, but that doesn't require introducing strong typing into php. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36853 — Christian Schneider — 2008-04-07T17:12:13+00:00 URL: https://externals.io/message/36827#36853 · In reply to: #36852 Stanislav Malyshev wrote: > I'm not sure I understand - how array_reduce is related to having type > hints? You could make array_reduce to do additional things, but that > doesn't require introducing strong typing into php. The relation between array_reduce and scalar type hints is that API start to enforce certain types where they should not just because the programmer thinks it is a good idea. Currently the third parameter $initial of array_reduce only allows int. So instead of allowing any zval and leaving it to the callback function to deal with it a specific type is enforced. You can work around this by checking for `NULL` inside the callback and initializing it there but that does not work either if you use a built-in function as callback. - Chris --- ## #36854 — Lukas Kahwe Smith — 2008-04-07T17:37:08+00:00 URL: https://externals.io/message/36827#36854 · In reply to: #36851 > Felipe Pena wrote: > > […] > > Just so this side was mentioned once again too: There are people who > consider type hints and especially scalar type hints A Bad Thing(tm) > as > it is contrary to the PHP strength of dynamic typing and automatic > type > conversion. Right if at all I would agree on having a type hint "scalar", but not a separate one per type. regards, Lukas --- ## #36855 — Lukas Kahwe Smith — 2008-04-07T17:39:42+00:00 URL: https://externals.io/message/36827#36855 · In reply to: #36852 > Hi! > > > […] > > I'm not sure I understand - how array_reduce is related to having > type hints? You could make array_reduce to do additional things, but > that doesn't require introducing strong typing into php. PHP should be as flexible about types as possible. I never used `array_reduce()` so I do not know its history. But some of you might remember the change in behavior from `array_merge()` which was the result of a switch to a more strict parameter parsing API, which now returns false when you pass in NULL. A fair amount of people believe that this is the wrong direction to take. Continuously expanding type hints relates to this concern. regards, Lukas --- ## #36856 — Stanislav Malyshev — 2008-04-07T17:59:20+00:00 URL: https://externals.io/message/36827#36856 · In reply to: #36854 Hi! > Right if at all I would agree on having a type hint "scalar", but not a > separate one per type. IMO (as already was discussed like 10 times?) "scalar" makes no sense. It doesn't save you any checks, and doesn't provide any useful information and can't perform any useful conversions, etc. for you. BTW, the statement to usefulness of "scalar" is that no C API function ever needed "scalar" as parameter type - and while we had a lot of formats for zend_parse_parameters, including objects, arrays, resources, numbers, strings of various kinds, callbacks, etc., we don't have "scalar" one. I consider it a strong indication that this idea is not as good as it might seem. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36858 — Richard Quadling — 2008-04-07T20:46:31+00:00 URL: https://externals.io/message/36827#36858 · In reply to: #36851 > Just so this side was mentioned once again too: There are people who > consider type hints and especially scalar type hints A Bad Thing(tm) as > it is contrary to the PHP strength of dynamic typing and automatic type > conversion. We are told that user data is dirty. Cleaning it is essential. One of the simplest ways is to cast the data to the right type. If they enter a date, then make sure it is a date by converting it to a date - if it can't convert then it wasn't a date. Why would you retain the string as your PRIMARY value? If you intend to do date manipulation you have to convert it. To use scalars they have to be in the right type. I cannot take 2 days from a string which is a date without having to do some conversion. The net result is that most user data should end up in the correct type anyway. So at what stage does this dynamic juggling of scalars take place? And why is it considered non-dynamic having a function declaration tell third party developers the scalar type of the parameters should be? If it was truly dynamic, they would be juggled for me rather than have me do it in userland. About the only time juggling is effective is in string concatenation. And even then it misses booleans! Do I get "true"/"false"? No I get nothing or 1. So I have to process it. Type juggling just doesn't seem to fit well with me. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #36859 — Christian Schneider — 2008-04-07T21:40:02+00:00 URL: https://externals.io/message/36827#36859 · In reply to: #36858 Richard Quadling schrieb: > Type juggling just doesn't seem to fit well with me. You seem to live in a completely different PHP world. Because in our case we use (yes, knowingly use) the PHP type juggling and it safes us lots of manual type conversions. We get input from all different sources as strings (_GET, MySQL, files) and in a lot of cases we just use it. We don't care if it's a string, a number or a float (or even null), if it yields the right result in our calculation it's fine. Now if a function only expects int (and truncates floats because of that) like array_reduce does with the $initial parameter then this function is crippled (for no good reason). Promoting type hints for PHP (and more so scalar type hints, especially specific scalar type hints like int) might give the impression to API developers that highly specified interfaces are better than more general ones. If we can learn something from the current hype around functional languages then it is the fact that generic, data type independant functions can be a very powerful tool. Something like array_* should be as generic as possible and API developers should also be aware of this topic and be given the right signals. Therefore my conclusion (abusing Einstein ;-)): Make interfaces as specific as *necessary* but *not more*. - Chris --- ## #36862 — Arvids Godjuks — 2008-04-08T09:02:40+00:00 URL: https://externals.io/message/36827#36862 · In reply to: #36859 I think type hint's would be good optional functionality. Those who need will use it, others will not. I'd probably use it in some cases. Especially if named parameters are implemented. Sometimes what I really want is named parameter pass like function myfunc(array $array, string $string = null, int $someint = 0){ } myfunc($myArray, someint = $mySomeInt); --- ## #36863 — krister.karlstrom@arcada.fi — 2008-04-08T09:17:36+00:00 URL: https://externals.io/message/36827#36863 · In reply to: #36862 Hi! This is maybe getting a bit out of topic now, but what about function/method overloading using type hinting: function myfunc(string $data) { } function myfunc(int $data) { } function myfunc(myClass $data) { } This currently causes an error in PHP 5.2.5 that function myfunc() can't be redeclared. This would in my opinion be very useful for methods in classes. Greetings, Krister Karlström, Helsinki, Finland Arvids Godjuks wrote: > I think type hint's would be good optional functionality. Those who need > will use it, others will not. I'd probably use it in some cases. Especially > if named parameters are implemented. > > Sometimes what I really want is named parameter pass like > > function myfunc(array $array, string $string = null, int $someint = 0){ > } > > myfunc($myArray, someint = $mySomeInt); > -- * Ing. Krister Karlström, Zend Certified Engineer * * Systemutvecklare, IT-Centralen * * Arcada - Nylands Svenska Yrkeshögskola * * Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland * * Tel: +358(20)7699699 GSM: +358(50)5328390 * * E-mail: krister.karlstrom@arcada.fi * --- ## #36864 — Arvids Godjuks — 2008-04-08T10:05:23+00:00 URL: https://externals.io/message/36827#36864 · In reply to: #36863 Em, you have __call method in classes - via it you could implement ANY logic for overloading. It's written in manual here: http://www.php.net/manual/en/language.oop5.overloading.php KISS should be followed - no C++ style overloading is needed, PHP is a script language without strict type hinting. 2008/4/8, Krister Karlström : > > Hi! > > This is maybe getting a bit out of topic now, but what about > function/method overloading using type hinting: > > function myfunc(string $data) { } > function myfunc(int $data) { } > function myfunc(myClass $data) { } > > This currently causes an error in PHP 5.2.5 that function myfunc() can't > be redeclared. This would in my opinion be very useful for methods in > classes. > > Greetings, > Krister Karlström, Helsinki, Finland > > Arvids Godjuks wrote: > > I think type hint's would be good optional functionality. Those who need > > […] > -- > * Ing. Krister Karlström, Zend Certified Engineer * > * Systemutvecklare, IT-Centralen * > * Arcada - Nylands Svenska Yrkeshögskola * > * Jan-Magnus Janssons plats 1, 00550 Helsingfors, Finland * > * Tel: +358(20)7699699 GSM: +358(50)5328390 * > * E-mail: krister.karlstrom@arcada.fi * --- Next page: https://externals.io/message/36827.md?page=2