Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80475
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <000301d02fd3$456ab390$d0401ab0$@tutteli.ch>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <000301d02fd3$456ab390$d0401ab0$@tutteli.ch>
Date: Wed, 14 Jan 2015 15:52:32 -0300
Message-ID: <CAOsHV+thK_3CbY8BQn+M5-jS8b54zqwmEKERKdXfSE1fVoQJSQ@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11345e322a5708050ca13f1c
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: marcio.web2@gmail.com (Marcio Almada)

--001a11345e322a5708050ca13f1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrea,

With all the respect this RFC is way worst than the v0.1:

We still have a BC break but now we also have code with **mutant** behavior
that might become buggy (do unexpected things) if a `declare` is used. As a
language user and a package maintainer it would be a huge problem. Imagine
how would be to maintain a package that can be used with both strict and
coercive type checking. We would have to write 2x more tests and yet
pollute code with manual type checks (is_string, is_integer)  for the non
strict runtime mode when type check is necessary.

This RFC is a huge regression, IMMO, -1 here

2015-01-14 5:22 GMT-03:00 Robert Stoll <php@tutteli.ch>:

> Hi Andrea
>
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: Andrea Faulds [mailto:ajf@ajf.me]
> > Gesendet: Mittwoch, 14. Januar 2015 01:17
> > An: PHP Internals List
> > Betreff: [PHP-DEV] [RFC] Scalar Type Hints v0.2
> >
> > Good evening,
> >
> > I=E2=80=99ve made some quite significant changes to my Scalar Type Hint=
s RFC,
> and bumped its version to 0.2.
> >
> > Here: https://wiki.php.net/rfc/scalar_type_hints
> >
> > This is a new thread because I=E2=80=99ve made a significant revision t=
o the
> RFC, so it=E2=80=99d be sensible to separate discussion of the
> > updated RFC from the v0.1 RFC.
> >
> > Please tell me your thoughts.
> >
> > Thanks!
> > --
> > Andrea Faulds
> > http://ajf.me/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit: http://www.php.net/unsub.php
>
> I had a few thoughts on the new proposed declare(strict_typehints=3DTRUE)=
;
> construct and I must say I do not really like that we would have differen=
t
> behaviour just based on a directive. This is quite ugly from a readabilit=
y
> point of view since I as user cannot easily see whether somewhere (above)
> in the code the directive was set (I have changed my mind a little bit
> below - left it here for traceability purposes). Which brings me to the
> question what happens with the following code:
>
> function foo(int $a){}  //is weak right?
> declare(strict_typehinting=3DTRUE);
>
>
> I guess it is weak since you wrote: "If this boolean value is TRUE, stric=
t
> type-checking mode is used for function calls in the remainder of the fil=
e"
> Maybe it is a good idea to add such an example to the examples as well.
>
> Now, having rethought my own email, I think we should enforce some code
> style to avoid a huge mess. Why not declare that the directive needs to b=
e
> the very first statement inside a namespace scope (unless the directive
> block syntax is used). This way it would be easily verifiable for the use=
r
> if strict mode is in place or not. But then again, we could also argue th=
at
> is up to code conventions/code guidelines and they should specify whether
> mixing both modes is ok and where the directive has to be placed. So
> re-rethinking what I just wrote I would say it is fine as it is now but w=
e
> should at least consider if we want to enforce some code practice to avoi=
d
> a mess.
>
> Now another point: "Whether or not the function being called was declared
> in a file that uses strict or weak type checking is entirely irrelevant.
> The type checking mode depends on the file where the function is called."
> Seems quite strange to me but fair enough, why not -- actually makes
> perfectly sense for this RFC -> leaving it to the user to decide what
> he/she likes :-)
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11345e322a5708050ca13f1c--