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
