Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84983
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZPtU7NWZnSvaSXPreH=AHKMrSGZ6ePz3W0TQ1BNF0MB=sTFg@mail.gmail.com>
References: <CAAyV7nFAE07s+o8xW6fYwAu2-goo3riWuuWSTZn4hTo5O58HrA@mail.gmail.com>
 <CAGa2bXZrmQuzCTQ=E8gkGU-N2wV459PfL2VCdmeu_+JQD17LEQ@mail.gmail.com>
 <CAEZPtU7_vEpF=pLQfcF6Y9n-TU4K5D-zxHiSD-bw65S4zsS-ag@mail.gmail.com>
 <CAGa2bXa6P-euEB_h2q1w9wb=Ms6N0DRSe3eDp0rwJx98cqz6sQ@mail.gmail.com> <CAEZPtU7NWZnSvaSXPreH=AHKMrSGZ6ePz3W0TQ1BNF0MB=sTFg@mail.gmail.com>
Date: Mon, 16 Mar 2015 14:44:30 +0900
Message-ID: <CAGa2bXbu=SDOTwNr9S4EcmLC9UioekwZBOg01dCCe-E=3-EEng@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Anthony Ferrara <ircmaxell@gmail.com>
Content-Type: multipart/alternative; boundary=001a113cfe5c76137a0511615aa1
Subject: Re: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date Change
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113cfe5c76137a0511615aa1
Content-Type: text/plain; charset=UTF-8

Hi Pierre,

On Mon, Mar 16, 2015 at 12:31 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> > I'm not saying the proposed patch has bugs, but I'm saying it hides
> "users' code bugs".
> >
> > Hiding hard to find bugs does not make much sense while there is the
> proposal that finds it.
> > What I'm trying to say is "Why don't we collaborate?". Let users fix
> bugs at first, then
> > introduce more strict type checks if it's needed. Coercive type and
> strict type can co-exist
> > together well, but weak type and strict type cannot.
>
> This example is out of the scope of this rfc. As I said many times, you
> want to make php more friendly and let users write better code, that's a
> good thing. However changing by default how php behaves for decades is a no
> go for me. It will create more issues than it solves.
>

Whether we like or not, languages that support type safety are getting
popularity
even for web app development in these days. What Zeev is proposing is
common
conversion rules that many languages support already. If we are going to
support
type safety in some forms, we should try to adopt well established rules if
it is
available. I'm not objecting ZVAL type check only strict typing, but I'm
suggesting
Zeev's proposal is more suitable for weakly typed PHP. It works well with
strict type
also.

Introducing type safety is the objective of scalar type hints. In other
words, let users
enjoy less bug programs by systematic support. IMO. What we should think is
"do
it right or not". Hiding type related bugs by enforcing C language like
type is not good
at all. IMHO.

I'm 100% sure that users will have bad codes with this RFC from my code
auditing
experience. In contrast, Zeev's proposal will prevent "bad codes" nicely
and effectively.
That's the reason why I prefer the proposal.

PHP is made to be a nice an easy web app language. It's clear to me which
one is
preferred choice for introducing type hints for "now".

I understand concern about old code compatibility. If currently proposed
migration term
is not enough, we may extend it by other RFC. There is enough time until we
introduce
destructive change. We may change migration period at any time with users
feedback.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113cfe5c76137a0511615aa1--