Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <005001d03f23$0a3253a0$1e96fae0$@tutteli.ch>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com>
	<003d01d03f17$e1c16510$a5442f30$@tutteli.ch>
	<CA+9eiLsZV+ujNOJZZ=5xuh1TmsjLVFvuV9Vr8S9BB+O+kyxjiA@mail.gmail.com>
	<005001d03f23$0a3253a0$1e96fae0$@tutteli.ch>
Date: Tue, 3 Feb 2015 00:43:12 +0400
Message-ID: <CA+9eiLtfC88NdKG4yM8y=R+kPuw_uysNVPbnqsYr0gTUxSeo+A@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: PHP Internals <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=089e0115fd02c35176050e210093
Subject: Re: AW: [PHP-DEV] What do we need strict scalar type hints for?
From: dmitry@zend.com (Dmitry Stogov)

--089e0115fd02c35176050e210093
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Feb 2, 2015 11:02 PM, "Robert Stoll" <php@tutteli.ch> wrote:
>
> > -----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?
> >
> > On Mon, Feb 2, 2015 at 9:41 PM, Robert Stoll <php@tutteli.ch> wrote:
> >
> > > 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 certai=
n
> > > 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 b=
e
> > > 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=
?
> >
> >
> > no. now we speak only about parameter and return value type hints.
>
> [Robert Stoll]
> Could be addressed in another RFC then.
>
> >
> >
> > > Would somehow be the logical consequence but I suppose the impact on
> > > performance would be too big. Or wouldn't it?
> > >
> >
> > it wouldn't reduce performance. may be even increase, but it'll break
every second app.
> >
>
> [Robert Stoll]
> 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?

I don't think we will implement strict semantic for operators.
It's not going to be PHP anymore....
$s =3D (string)$a . (string)$b;

>
> >
> > > 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.
> > >
> >
> > 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.
> >
>
> [Robert Stoll]
> 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.
> 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.

Yes. But this not about strict vs weak. This is about conversion rules,
that we may change in a more cosistent way.

Thanks. Dmitry.

>
>
> [1] http://tsphp.ch

>
> > Thanks. Dmitry.
> >
> >
> > >
> > > Hope that helps.
> > >
> > > Cheers,
> > > Robert
> > >
> > >
> > >
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > > visit: http://www.php.net/unsub.php
> > >
> > >
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--089e0115fd02c35176050e210093--