Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81643
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: "'Dmitry Stogov'" <dmitry@zend.com>
Cc: "'PHP Internals'" <internals@lists.php.net>,
	"'Andrea Faulds'" <ajf@ajf.me>,
	"'Nikita Popov'" <nikita.ppv@gmail.com>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com>	<003d01d03f17$e1c16510$a5442f30$@tutteli.ch> <CA+9eiLsZV+ujNOJZZ=5xuh1TmsjLVFvuV9Vr8S9BB+O+kyxjiA@mail.gmail.com>
In-Reply-To: <CA+9eiLsZV+ujNOJZZ=5xuh1TmsjLVFvuV9Vr8S9BB+O+kyxjiA@mail.gmail.com>
Date: Mon, 2 Feb 2015 21:01:31 +0100
Message-ID: <005001d03f23$0a3253a0$1e96fae0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQI+MKsMv6zrm7KCv5jpZIs/BqhffwEEDRckAM6bJVGb80Pm8A==
Content-Language: de-ch
Subject: AW: [PHP-DEV] What do we need strict scalar type hints for?
From: php@tutteli.ch ("Robert Stoll")

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Dmitry Stogov [mailto:dmitry@zend.com]
> Gesendet: Montag, 2. Februar 2015 20:14
> An: Robert Stoll
> Cc: PHP Internals; Andrea Faulds; Nikita Popov
> Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
>=20
> On Mon, Feb 2, 2015 at 9:41 PM, Robert Stoll <php@tutteli.ch> wrote:
>=20
> > Hi Dimitry,
> >
> > > -----Urspr=C3=BCngliche Nachricht-----
> > > Von: Dmitry Stogov [mailto:dmitry@zend.com]
> > > Gesendet: Montag, 2. Februar 2015 10:13
> > > An: PHP Internals; Andrea Faulds; Nikita Popov
> > > Betreff: [PHP-DEV] What do we need strict scalar type hints for?
> > >
> > > hi,
> > >
> > > could you please write down few use cases, when strict scalar type
> > > hints
> > are really useful.
> > >
> > > Thanks. Dmitry.
> >
> > I think strict types are beneficial in all those places where you
> > would put manual tests to ensure that the passed value is of a =
certain
> > type and only of this type - removing the hassle (ok, I did not add
> > anything to the discussion so far ^^). Right now, I mainly think of
> > functions which expect an int - especially in the domain of time and
> > money.  I would expect an int and I would not want that a float can =
be
> > passed without warning and get silently converted to an int (loosing
> > precision in the domain of time or money can be crucial).
> >
> However, IMO it is not necessary to have a strict mode as presented by
> > Andrea -- I think it would be good enough if we use the same =
widening
> > rules as in Java, C# etc. and be strict otherwise. I am aware of =
that
> > with the support of BigInteger we would have a widening problem
> > (BigInteger to
> > float) but could be solved by a BigDecimal as in Clojure.
> >
> > Ah... I now something I would definitely want to be strict. I guess =
a
> > typical bug, which is made by many beginners, is using the result of
> > strpos in an if statement without using the identity operator -- =
btw.
> > would the strict mode affect operators and control structures as =
well?
>=20
>=20
> no. now we speak only about parameter and return value type hints.

[Robert Stoll]=20
Could be addressed in another RFC then.

>=20
>=20
> > Would somehow be the logical consequence but I suppose the impact on
> > performance would be too big. Or wouldn't it?
> >
>=20
> it wouldn't reduce performance. may be even increase, but it'll break =
every second app.
>

[Robert Stoll]=20
I wrote it a little bit ambiguously, I actually meant a negative big =
impact on performance. Concerning the second part of your sentence. As =
other already mentioned, it would not break every second app since only =
those apps would be concerned which enable the strict mode and even then =
only those files are concerned which are written by the owner of the =
code and the owner oneself decided to use the strict mode, ergo =3D> =
everything is fine as long as the owner writes strict code and if she/he =
does not, then it actually must break since the owner of the file made a =
mistake in terms of strictness and wished to be informed about it. Makes =
sense no?
=20
>=20
> > Back to the topic, if I expect a bool as parameter I would =
definitely
> > not want it to be automatically converted since this is a sink for =
bugs.
> >
>=20
> I'm not sure. If we would work on a type-safe language I would =
definitely agree, but PHP is a "loosely typed language" by
> definition.
>=20

[Robert Stoll]=20
I agree, PHP is weakly typed and that is fine. Yet, if we are discussing =
what strict types would be useful for then the mentioned examples are =
good use cases IMO.=20
Personally, I think weak type hints as suggested in the RFC might be a =
way to go for PHP [*] where in a type-safe version of PHP (such as TSPHP =
[1]) it would not make sense at all.

[*] even though I think it is really ugly that a float or a float in a =
string can be passed to a function expecting an int. IMO only those =
values should automatically converted where it can be guaranteed that no =
precision is lost. Maybe I have not read the RFC carefully enough - =
following some examples to illustrate what I mean:

function foo(int $i){}
foo(1);       //ok
foo(2.0);   //still fine
foo("2");   //acceptable as well
foo('3.0'); //even this is ok

foo(1.4);       //ouch
foo("1.2");   //please no
foo("1lxs");  //oh no.. please... noooo ^^

Well, yeah... I guess you get my point.


[1] http://tsphp.ch

> Thanks. Dmitry.
>=20
>=20
> >
> > Hope that helps.
> >
> > Cheers,
> > Robert
> >
> >
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
> >
> >