Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75441
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20140713101840.GR6540@phcomp.co.uk>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
	<53C2178E.7070705@sugarcrm.com>
	<53C24061.6050503@lsces.co.uk>
	<20140713101840.GR6540@phcomp.co.uk>
Date: Mon, 14 Jul 2014 14:19:15 +0200
Message-ID: <CAH-PCH5jXupEzpsgdF9xCwnGajMsDw7kF137iCJmpz++Wq9GTw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2caa2ac969d04fe264cb9
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c2caa2ac969d04fe264cb9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 13, 2014 at 12:18 PM, Alain Williams <addw@phcomp.co.uk> wrote:

> 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 perhap=
s
> > 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 mak=
es
> 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 =3D=3D $b'' could be an integer
> comparison
> rather than having to first determine what the types might be and then en=
d
> 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 belo=
w)
>     }
>
> 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 ?
>
>
I think it would be better to reuse declare() instead of reusing var.
What error level would it emit though?
I anything below E_RECOVERABLE_ERROR, then it doesn't do anything, but
prints a line to the error log(and or displays it), which we already do,
because using an undefined variable will emit an E_NOTICE
I think it is a good thing if we make it easier to spot programming errors
and bail out early instead of trying to guess the developer's intention,
but I don't think that adding more fatal errors or
E_RECOVERABLE_ERRORs(which will be fatal if there is no userland error
handler defined which explicitly allows to continue the execution).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c2caa2ac969d04fe264cb9--