On 02/03/15 09:47, Zeev Suraski wrote:
I'm obviously biased but I believe that the coercive rules actually cover a
lot more ground than the weak+strict sets. In other words, with
weak+strict, overall, you're going to have to add custom code in a lot more
cases than with the coercive rule set
-Original Message-
From: Lester Caine [mailto:les...@lsces.co.uk]
Sent: Monday, March 02, 2015 12:10 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated
RFC
On 02/03/15 09:47, Zeev Suraski wrote:
I'm obviously
-Original Message-
From: Thomas Punt [mailto:tp...@hotmail.co.uk]
Sent: Sunday, March 01, 2015 4:03 PM
To: Zeev Suraski; PHP internals
Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated
RFC
Hey Zeev,
Another change being considered and not yet in the RFC
-Original Message-
From: Lester Caine [mailto:les...@lsces.co.uk]
Sent: Monday, March 02, 2015 11:31 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated
RFC
Andrea's post highlights the fact that we did try a fix when PHP5 came
On 02/03/15 08:39, Zeev Suraski wrote:
One scenario I have in mind for this is validating $_GET information for a
RESTful web service. Having potentially an infinite number of URIs that all
point to the same resource isn't good:
/users/1
/users/%201
/users/1%20
/users/%201%20
Hey Zeev,
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
I think that rejecting leading and trailing spaces for stringy ints is for the
best.
If I only want to accept an integer (in either int or string
De : Brian Moon [mailto:br...@moonspot.net]
I agree here with Benjamin. The thing I have wanted in user land for
years is to be able to build a user land function that worked the way
internal functions do in terms of type checking without having to build
my own type checking system. Having
De : Damien Tournoud [mailto:d...@damz.org]
All those are due to a bug in substr(), that we see now only thanks to
proper type identification. There is no reason for substr() to ever return
a boolean. It really needs to be fix to always return a string.
Sorry, not a bug. Documentation is
On 28/02/15 08:40, François Laupretre wrote:
My opinion, but that's only mine, is that I would favor deprecating null to
scalar, even for internal functions. It would add deprecation messages but
we'd end up with a cleaner code.
null is a very specific 'state' for anybody working with
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
The funny thing is that the fix for this is:
- substr($image, strrpos($image, \n) + 1)
+ (string)substr($image, strrpos($image, \n) + 1)
Which is that sort of casting that is put forward as argument against the
dual/strict mode.
It is
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
Interestingly functions like is_infinite(), is_dir(), is_file() all expect
correct types like float or string here although from the naming convention
is_something i would expect it says just false on *anything* else (which
it almost does
De : Damien Tournoud [mailto:d...@damz.org]
But anyway, that's not even the point. The point is that return values that
worked in a world of transparent type-jungling will not work in a world
of stricter typing checks. Which means that we need:
(1) To accept that for now casting FALSE to
On 28/02/15 08:24, François Laupretre wrote:
Sorry, not a bug. Documentation is clear. You get 'string|false' from
substr() and send it to a function expecting 'string'. Most languages will
fail on this. It worked in PHP because of implicit casting from bool to
string. We just decided to
Hi Christian,
On Fri, Feb 27, 2015 at 5:15 PM, Christian Stoller stol...@leonex.de
wrote:
In this case FALSE is an expected result and it is intended. And as
I said other languages are going the same way.
Other languages are also doing something saner. It's not really an argument
either way.
This RFC trying to simpliy and cleanup the coercison rules, having two
different conversion rules for NULL-scalar
depending on userland or internal is counter-productive and bad. The
behavior you describe as null being
empty value is wide-spread in PHP userland code as well.
I agree here with
On 27/02/15 14:15, Benjamin Eberlei wrote:
Imho the problem is that the return values of php internal functions being
string|false will lead to massive consecutive errors when passing this on
to other internal functions.
This is perhaps the crux of my objection to both types of 'error
On 27/02/15 16:46, Damien Tournoud wrote:
You probably haven't read the examples that I pasted. If you think that it
makes sense to return an error code if the function is called with invalid
arguments, it should be done consistently. The current behavior is just an
absurdly inconsistent, it
On 27/02/15 13:45, Benjamin Eberlei wrote:
Drupal admin interface (across the all pages): One new E_DEPRECATED
warning, which again seems to catch a real bug - stripslsahes()
operating
on a boolean.
All those are due to a bug in substr(), that we see now only thanks to
proper
On Fri, Feb 27, 2015 at 2:57 PM, Lester Caine les...@lsces.co.uk wrote:
On 27/02/15 13:45, Benjamin Eberlei wrote:
Drupal admin interface (across the all pages): One new E_DEPRECATED
warning, which again seems to catch a real bug - stripslsahes()
operating
on a boolean.
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015
2:38 PM
Hi Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
real bug, or at least faulty looking code:
$path =
On Fri, Feb 27, 2015 at 2:37 PM, Damien Tournoud d...@damz.org wrote:
Hi Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@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,
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Friday, February 27, 2015 1:19 PM
To: Dmitry Stogov
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated
RFC
On Fri, Feb 27, 2015 at 9:44 AM, Dmitry
Hi Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@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;
On Fri, Feb 27, 2015 at 2:37 PM, Damien Tournoud d...@damz.org wrote:
Hi Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@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,
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015
4:54 PM
Hi Christian,
On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de wrote:
It is not a bug. FALSE as a return value of substr() is the identificator
for an error (e.g. invalid arguments), as
Cristian,
All those are due to a bug in substr(), that we see now only thanks to
proper type identification. There is no reason for substr() to ever return
a boolean. It really needs to be fix to always return a string.
Damien
It is not a bug. FALSE as a return value of substr() is the
Hi Christian,
On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de
wrote:
It is not a bug. FALSE as a return value of substr() is the identificator
for an error (e.g. invalid arguments), as it is stated in the
documentation:
[...]
It is documented that way and it is not a
Hi Lester,
On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine les...@lsces.co.uk wrote:
This may not be what YOU want substr to do and it would perhaps be
useful to ADD additional checks so that 'false' is returned when it
can't created a string because of the 'invalid arguments', but type
hints
On 27/02/15 20:28, Damien Tournoud wrote:
Hi Lester,
On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine les...@lsces.co.uk
mailto:les...@lsces.co.uk wrote:
This may not be what YOU want substr to do and it would perhaps be
useful to ADD additional checks so that 'false' is returned
Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
All,
We've been working in the last few days to test and tune the Coercive STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Can we try the patch ourselves? I
Hi Lester,
On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine les...@lsces.co.uk wrote:
Please, read the examples again, the current behavior is nothing but
inconsistent:
substr(a, 1) = FALSE
substr(a, -300) =
? That was the case prior to PHP5.2.1
The fixes in 5.2.2 were not
I've added the link to the patch
https://github.com/php/php-src/pull/1125/files
Thanks. Dmitry.
On Fri, Feb 27, 2015 at 11:03 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
Zeev,
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
All,
We've been working in the last
On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov dmi...@zend.com wrote:
I've added the link to the patch
https://github.com/php/php-src/pull/1125/files
Thanks!
First, the necessary PHPUnit changes (dev-master) to avoid errors:
https://gist.github.com/beberlei/8a33ae940829f1186da2
- Doctrine
On 2/27/15 10:15 AM, Christian Stoller wrote:
From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015
4:54 PM
Hi Christian,
On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller stol...@leonex.de wrote:
It is not a bug. FALSE as a return value of substr() is the
On 27/02/15 21:14, Damien Tournoud wrote:
Hi Lester,
On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine les...@lsces.co.uk
mailto:les...@lsces.co.uk wrote:
Please, read the examples again, the current behavior is nothing but
inconsistent:
substr(a, 1) = FALSE
On Fri, Feb 27, 2015 at 12:18 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov dmi...@zend.com wrote:
I've added the link to the patch
https://github.com/php/php-src/pull/1125/files
Thanks!
First, the necessary PHPUnit changes (dev-master)
Hi Pierre,
De : Pierre Joye [mailto:pierre@gmail.com]
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.
The RFC now contains a table listing the changes compared to current PHP 5
rules. Enjoy it.
How many deprecations do you get running the ZF2 and Symfony testsuites?
None, but it may have to do with the fact I haven't run them yet :)
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 26, 2015 at 3:57 PM, Zeev Suraski z...@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
On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski z...@zend.com wrote:
All,
We've been working in the last few days to test and tune the Coercive STH
patch. I think the results are quite nice, and surprisingly better than
one might have expected.
Before diving into the results, we did
Hi Zeev,
On 26 February 2015 at 23:57, Zeev Suraski z...@zend.com wrote:
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
Not to worry. I know where Github keeps the servers ;).
There are far worse things than
De : Pierre Joye [mailto:pierre@gmail.com]
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.
Yes, even if we don't really 'catch' things, because we just raise E_DEPRECATED
and, then,
42 matches
Mail list logo
