On Sun, Jul 13, 2014 at 09:16:33AM +0100, Lester Caine wrote: > On 13/07/14 06:22, Stas Malyshev wrote: > > It is very direct specification of > > either strict parameter typing or coercive parameter typing. I don't > > think using confusing terminology helps anything here. I think it was a > > mistake to introduce this term from the start and we should stop > > propagating it. > > It does come across as as an attempt to hide the 'strict parameter > typing' which is something that is very much less attractive. If I > wanted that then I'd simply switch back to C/C++ direct which is perhaps > where we are now heading anyway with the increasing use of pre-compiled > application code? > > One of the reasons I persist with PHP is the fact that many of my users > can adjust the odd PHP file correcting sequence or modifying text > without having to learn the intricacies of formal programming. It's > adding all these complex layers that is taking PHP away from it's more > novice friendly base ... If you want a formal programming language then > just use one?
I don't see the current PHP type juggling as 'formal programming'. It makes things easy but can also lead to bugs where unexpected values (& so types) end up being inappropriately used. This RFC does not mandate the use of type hinting so your users can still get away with quick/sloppy programming. That does not change. However: it does allow others to gain extra assurance that their programs are not dealing with bad values (& so types) if they wish to. I can see that the first areas where this will be used will be in objects/libraries that others use. It will be good to use type hinting to bring out bugs where a bad value has slipped by validation. The users of such libraries would not need to make changes as a result of this. I can see that it will also allow run time optimisation. If a value is known to contain an integer then code like ''$a == $b'' could be an integer comparison rather than having to first determine what the types might be and then end up doing integer compare. So: I strongly support this RFC. I would also like to suggest an addition. That is the ability to declare local variables to functions maybe using the using the keyword 'var'. So you would go: function foo(int $a) { var $b; // $b has no type hinting var float $c; // $c is a float string $d; // alternative to the syntax used for $c (see below) } I would like, eventually, PHP to have a mode where use of an undeclared variable would lead to an error being raised. A model for this is perl's ''use strict''. The way that this could be done in PHP is that if a variable is declared with 'var' then strict mode is switched on for the function. This would provide a distinction between the above declarations for $c and $d ($c switches on strict mode, $d does not). This would be OPTIONAL - ie if you do not want it then do not use 'var' and it will not impinge; if you use it then you get the extra checking that it brings. Should I raise an RFC for this ? -- 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 #include <std_disclaimer.h> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php