Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: =?utf-8?Q?'Pavel_Kou=C5=99il'?= <pajousek@gmail.com>
Cc: "'Zeev Suraski'" <zeev@zend.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<002101d04ea0$d92ea0f0$8b8be2d0$@tutteli.ch> <CAB6YZuzKZAiSbzq7+yOsZ4wqKMTR1myemuPqEsDUAqpNzMnHBg@mail.gmail.com>
In-Reply-To: <CAB6YZuzKZAiSbzq7+yOsZ4wqKMTR1myemuPqEsDUAqpNzMnHBg@mail.gmail.com>
Date: Sun, 22 Feb 2015 19:30:05 +0100
Message-ID: <000601d04ecd$95545aa0$bffd0fe0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKcPg+jpyYspJS11b5G1A7RBHpKTgIhFZZKAamJpWybRseZwA==
Content-Language: de-ch
Subject: AW: [PHP-DEV] Coercive Scalar Type Hints RFC
From: php@tutteli.ch ("Robert Stoll")

Hi Pavel,

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Pavel Kou=C5=99il [mailto:pajousek@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 15:54
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>=20
> On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll <php@tutteli.ch> wrote:
> >
> > I see the migration plan roughly as follows:
> >
> > PHP 7.0:
> >   - reserve keywords: bool, int, float including alternatives
> >   - deprecate alternative type names such as boolean, integer etc.
> >
> >   - introduce new conversion functions which reflect the current =
behaviour of (bool), (int) etc.
> >       --> as mentioned above, they could be named =
oldSchoolBoolConversion etc.
> >       --> Encourage users to use this function instead of (bool),
> > (int) etc since (bool) etc. will change with PHP 8.0. Also mention,
> > that this function should only be used if the weakness is really
> > required otherwise use the new conversion functions from below
> >
> >   - introduce new conversion functions which reflect the new defined =
conversion rule set (which shall be the only one
> encouraged in the future) Those functions shall trigger an =
E_RECOVERABLE_ERROR
> >     --> encourage users to use this functions instead of (bool), =
(int)
> > and oldSchoolBoolConversion etc.  (unless the weakness is really
> > required, then use oldSchoolBoolConversion)
> >
> >   - update the docs in order to reflect the new encouraged way. Also =
mention that:
> >      - (bool), (int) etc. will change their behaviour in PHP 8.0
> >      - internal functions will use the new conversion rules if not =
already done this way in PHP 8.0 (for instance, strstr will no
> longer accept a scalar as third parameter in the case where we do not =
support implicit casts to bool)
> >      - operators will use the new conversion rules if not already =
done this way in PHP 8.0
> >      - (control structures will use the new conversion rules if not
> > already done this way in PHP 8.0) =3D>Maybe this is too strict for =
most
> > of you and goes against the spirit of PHP (I suppose some of you =
will
> > say that - fair enough, I guess you are right). In this case, I =
would
> > at least use the term "loose comparison" as mentioned here:
> > =
http://php.net/manual/en/types.comparisons.php#types.comparisions-loos
> > e instead of using the term "conversion", then it is compatible with
> > the changes introduced in PHP 8.0
> >
> > PHP 7.1: necessary bug-fixes introduced with PHP 7.0 PHP 7.x:
> > deprecate even more if required PHP 8:
> >   - introduce scalar type hints which reflect the conversion rules =
as defined (adding strict type hints as well is possible of
> course, whether with an ini-setting, a declare statement or =
individually with a modifier something like "strict int" for a single
> parameter or strict function for all parameters incl. return type or =
strict class for every type defined in the class is up to
> discussion)
> >   - exchange the behaviour of (bool), (int) etc. -> use the new =
conversion rules instead
> >   - change internal functions which do not yet obey to the new =
conversion rules
> >   - change the operators which do not yet obey to the new conversion =
rules (for instance, + would also emit an
> E_RECOVERABLE_ERROR for "a" + 1)
> >   - (change the control structures in order that they obey the new
> > conversion rules as well) =3D> as mentioned above, probably too =
strict
> > for PHP
> >
> > Back to this RFC.  think this RFC goes in the right direction with =
the specified conversion rules. Only thing to get rid of are
> the implicit conversions to bool from string, float and int IMO.
> > Moreover, I like that the RFC already has different steps for adding =
the new behaviour. Yet, I think it should slow down a
> little bit as shown. I think we need more time to come up with a very =
good strategic solution.
> >
>=20
> Hello,
>=20
> Am I understanding correctly that you are suggesting changes to type =
casting? This seems like a bad idea. Explicit and
> implicit conversions are something really different. Generally, =
implicit conversions are OK only when no data is lost and
> explicit conversions (casts) are used when you realize some =
information can get lost and you still want to proceed with the
> conversion. Having only one type of conversion is IMHO weird.

Yes, I am suggesting to make conversions behave the same regardless if =
it is implicit or explicit. The only difference between the two should =
be that one is stated explicitly by the user where the other is applied =
implicitly. Other programming languages behave like this and are more =
predictable for users as well as developers because one does not need to =
learn two sets of conversion rules.

>=20
> Also, I'm not a fan of having to wait for scalar type hints for few =
more years. :(
>=20
> Regards
> Pavel Kouril
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, =
visit: http://www.php.net/unsub.php