Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83941
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com>
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com>
Date: Thu, 26 Feb 2015 16:32:02 -0800
Message-ID: <CAEZPtU55N9XQWFVvRBdO0HQUhQvsffFbVnyd2GZ6sFp0L_J9_w@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Feb 26, 2015 at 3:57 PM, Zeev Suraski <zeev@zend.com> wrote:

> Drupal homepage:  One new E_DEPRECATED warning, which seems to catch a
> real bug, or at least faulty looking code:
>   $path = trim($path, '/');  // raises E_DEPRECATED, as $path is boolean
> false.
>   return $path;

So far nobody answered this question but Francois (tried). You keep
using this E_DEPRECATED message as a safety net to catch possible bad
things. What's about other changes that may not match the current
casting rules (or lack of) and will be different with this RFC? Those
considered as "Yes". This is what I worry about, even if minimal these
cases are pains to track down and fix.

Also I would really like a clear table describing in details what will
be changed, to compare how it works now and how it work later. This is
something that is crystal clear with the dual mode RFC, nothing
changes by defaullt, and strict rules if strict mode is enabled for a
file.

As you would expect, I will vote no as it is proposed now.