On Mon, Sep 8, 2014 at 9:26 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Nikita,
On weekend I ran PHP test suite with valgrind and opcache.
I noticed few new tests failures, that most probably introduced by AST
patch.
Bug #21820 ($arr['foo'] generates bogus E_NOTICE, should be E_PARSE)
How about delaying that warning until the headers are sent?
I don't think there would be any benefit to that. The only possible
scenarios are:
i) People sending duplicate headers by accident. When they see the
error, they should fix their code, so the error goes away.
ii) People who are
On 8 September 2014 09:09, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan theanomaly...@gmail.com
wrote:
Actually, we shouldn't be doing that all. We should simply just overwrite
the header. It wouldn't make much sense to set two headers with the same
From: Andrey Andreev
Sent: Monday, September 8, 2014 5:16 PM
To: Andrea Faulds
Cc: Adam Harvey, Christoph Becker, PHP internals
On Tue, Sep 9, 2014 at 3:07 AM, Andrea Faulds a...@ajf.me wrote:
On 8 Sep 2014, at 23:58, Adam Harvey ahar...@php.net wrote:
+1 on ?? — there's
Hi Matt,
On Fri, September 5, 2014 20:05, Matt Wilmas wrote:
Hi Anatol,
- Original Message -
From: Anatol Belski
Sent: Tuesday, September 02, 2014
Unfortunately that's not a PR so I cannot comment there directly, so
I'd
leave a couple of the comments to the code here:
It
On 09/09/2014 18:08, rpar...@yamiko.org wrote:
I agree and think we should go with a different operator as others suggested.
If not ?? than we could use ?= like $foo ?= “default string”.
That reads like an assignment, rather than an expression - particularly
given PHP's large number of
Hi Internals,
I would like to propose giving pack() and unpack() 64 bit format
codes, mimicking the current behaviour of 32 bit format codes.
Pack and unpack are obviously functions inspired by Perl, which has
the 64 bit format codes 'q' and 'Q'. So the first half of my proposal
is to give
Heya,
I remember that some people were complaining about the inconsistencies
between normal conversions and the one applied in Andrea's RFC about Scalar
Type Hinting With Casts.
https://wiki.php.net/rfc/scalar_type_hinting_with_cast
As an example:
$i = (int) a; //fine without errors
function
On 9 Sep 2014, at 19:36, Leigh lei...@gmail.com wrote:
Hi Internals,
I would like to propose giving pack() and unpack() 64 bit format
codes, mimicking the current behaviour of 32 bit format codes.
What would this do on 32-bit platforms?
Pack and unpack are obviously functions inspired by
On 9 Sep 2014, at 20:26, Robert Stoll p...@tutteli.ch wrote:
Personally, I do not like such inconsistencies either but I like that the
conversion rules in Andrea's RFC are more strict. And thus I was asking
myself if it would not make sense to change the current behaviour of
castings and
On 9 September 2014 21:16, Andrea Faulds a...@ajf.me wrote:
Why is there no big/little-endian signed long long?
Because there is no big/little-endian signed long :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 9 September 2014 21:16, Andrea Faulds a...@ajf.me wrote:
Why is there no big/little-endian signed long long?
I suppose you could argue that these count
i - signed integer (machine dependent size and byte order)
I - unsigned integer (machine dependent size and byte order)
However they
Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:
https://wiki.php.net/rfc/remove_alternative_php_tags
It removes % and script language=php and the other variations of asp and
script tags.
Nikita
Hi!
No, no it would not. PHP’s explicit casts cannot fail, and there is
absolutely no good reason to change this. If people want strict
casting, we can add new functions or operators for that specifically.
But to break explicit casts and make them sometimes fail would cause
innumerable bugs
On 9 September 2014 23:08, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:
https://wiki.php.net/rfc/remove_alternative_php_tags
It removes % and script language=php and the other
On 9 Sep 2014, at 23:08, Nikita Popov nikita@gmail.com wrote:
I've created a small RFC proposing the removal of the alternative PHP
opening/closing tags:
https://wiki.php.net/rfc/remove_alternative_php_tags
It removes % and script language=php and the other variations of asp and
On 10 Sep 2014, at 01:21, Andrea Faulds a...@ajf.me wrote:
Isn’t this a bit of a needless BC break? Not very nice on people with such
codebases. It’s also worth pointing out that people might be using these to
get around the XML ? issue (granted, you can disable short tags).
I’d vote for
Hi!
No, no it would not. PHP’s explicit casts cannot fail, and there is
absolutely no good reason to change this. If people want strict
casting, we can add new functions or operators for that specifically.
But to break explicit casts and make them sometimes fail would cause
innumerable
Hi,
When I was fixing test cases on my `kill-ereg` branch I noticed a Reflection
test case for `ReflectionFunction::isDeprecated()`.
The problem with such a test case is that you’d be chasing deprecated functions
to tests against as we move along; this is the current list of deprecated
On Tue, Sep 9, 2014 at 11:42 PM, Tjerk Meesters
tjerk.meest...@gmail.com wrote:
Hi,
When I was fixing test cases on my `kill-ereg` branch I noticed a Reflection
test case for `ReflectionFunction::isDeprecated()`.
The problem with such a test case is that you’d be chasing deprecated
Hi!
Maybe it will be better to do this in another way: introduce an RFC to
add 'deprecated' keyword into the syntax like 'final' or 'protected'.
There are many frameworks that want to deprecate some methods or
classes. Currently it's only possible via @deprecated tag in the
phpDoc-block, but this
21 matches
Mail list logo
