On Fri, Jul 18, 2014 at 7:02 AM, Theodore Brown <theodor...@outlook.com> wrote: >> Since I am very much in favour of scalar type hints, I've updated the >> patch to master and made some minor improvements, and I am re-opening >> the RFC with the intent to try and get it into PHP 5.7. > > First of all, this is my first reply on PHP Internals so I hope I am doing it > right. :) > > Thank you very much Andrea for reviving this RFC - I'm really looking forward > to using > something like this in the next version of PHP to more easily define > interfaces and > catch unintended errors in my code. > > However, something I feel it is important to consider is not just how scalar > type > annotations fit into the history of PHP, but how they fit with the way type > annotations > are currently used and where the language is going in the future. > > A recurring comment I've heard in the discussion for this RFC is that strict > type hints > aren't "the PHP way." However, current type hints for classes, arrays, and > callables > work exactly in this way - they do not allow nulls, no casting is performed, > and an > invalid type results in a fatal error. If scalar annotations are introduced, > many PHP > developers (myself included) would naturally expect them to behave in the > same way. > > Another concern I have is in regard to the future. I'm looking forward to the > possibility of specifying nullable types in a future version of PHP (see Levi > Morrison's "Declaring Nullable Types" RFC: > http://wiki.php.net/rfc/nullable_typehints). If the > nullable types RFC is accepted, it would be highly disconcerting if scalar > type > annotations allowed null values regardless of whether a nullable marker is > specified. > > I don't think that optional strict type annotations will take away from PHP's > dynamic > nature - they will instead be a valuable feature used in places where it is > necessary > to strictly validate a parameter's type - this is especially important to > ensuring > stability and accuracy in the large PHP applications it is my job to maintain. > > The RFC has already been updated to make boolean type annotations strict. > Doesn't it > make sense to treat the other scalar types in the same way? Perhaps a future > RFC could > propose a second (also optional) syntax to specify type annotations which > perform casts. > However, only having cast-based annotations for scalar types would be a > mistake, IMHO. > > -- > > Theodore Brown > > A PHP developer interested in the language's future > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Hi, all First of all, thanks for all your time, you put into this thread! I really am looking forward for a way, all can live with, because this topic has followed the PHP community since the release of PHP 5.1, since the introduction of type hinting for arrays (http://php.net/manual/en/language.oop5.typehinting.php). On an archive for this mailinglist I found threads that are going back to 2005 (http://marc.info/?l=php-internals&m=112397232722668&w=2) - Here's a list of all messages found: http://marc.info/?l=php-internals&s=type+hinting&q=b I've been one of the most active contributors to a thread back in 2012 - not the one giving most productive feedback, but the one giving the most feedback ... (I later saw a statistic of who posted the most mails to the mailinglist within the months of discussion) What I see, we're again stuck with mainly three different opinions, as Paul Biggar pointed out in his post - and he tried to find a solution back then. I would suggest that anyone should read this mail - if you want, read the thread - I haven't had the time for now..: http://marc.info/?l=php-internals&m=124653792412529&w=2 In every round we took this topic, there have been new RFCs added ... I don't know if there will be a solution, and my personal favorite is the way, proposed in this RFC here. No casting for the values, just more a validation - a lossy validation. The main reason for this proposal is, that mostly every input to your application will be a string. If it now is a file, a value from the database, the GET and POST parameters, a CURL response - nearly anything. I don't think it makes sense to first cast them before you can use them. I agree, that it feels wrong to have a method, accepting (string)"123abc" and casting it to (int)123 for internal usage, but it also feels wrong to not let the input (string)"123" pass as a parameter to a method accepting integer. This would lead us to casting (f.e. substr("string", (int)$var) ), what again would be like accept anything ($var = "abc"). I also saw some complaining about that older code may will not work when introducing something here. As of what I think, this should be implemented as an extension to the language as it is now. Old code should be able to run as it is. You may will get a problem when your old code is using a library, that you want to update and the library is using the new syntax ;) Thanks for reading. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
