Hey:
On Mon, Dec 8, 2014 at 6:03 AM, Andrea Faulds a...@ajf.me wrote:
Hi!
We’re now half-way through voting on this RFC, and only three people, two if
I’m excluded, have voted. I realise it’s a rather technical and obscure
matter, but I am a little worried by how few people have voted so
I don't see technical problems with the patch.
However, I also don't see any significant benefits.
From the user perspective it'll just change error messages and prevent
final final class declarations.
Nikita, what do you think?
Thanks. Dmitry.
On Fri, Dec 5, 2014 at 8:18 PM,
On 8 Dec 2014, at 08:22, Xinchen Hui larue...@php.net wrote:
the current warning message is : expects parameter 1 to be long,
double given in %s on line %d
but maybe it should be something like: expects parameter 1 to be
long, double(which is beyond long range) given in %s on line %d?
On 8 Dec 2014, at 06:24, Joe Watkins pthre...@pthreads.org wrote:
Morning Andrea,
I think it's okay to assume that people are winding down for the
holiday, possibly some people are already on holiday.
Because of the time of year, you might want to leave the vote open
another
On Thu, Dec 4, 2014 at 1:46 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Examples are COM, PDO Statement, DOM XML and MySQLi.
They also reduce the amount of checks of bison when parsing a php file, it
provides a nicer fatal error around multiple final and multiple abstract
On Mon, Dec 8, 2014 at 1:30 PM, Damien Tournoud d...@damz.org wrote:
PDO statement should not be made final, or this is a breaking language
change (requiring an RFC and a 2/3 majority).
I see from the PR that it's PDORow, not PDOStatement. That one is not
actually exposed as such to userspace,
Hi Dmitry,
As I said, these patches are not huge beneficial, but enablers. Enablers in
the sense that further development over class/interface/trait simplified.
It's not a short win benefit, but a mid/long term.
Also defer currently checks done in zend_compile to Bison (such as trait
extends and
Hi,
I've published a patch for bug #65576 :
https://github.com/php/php-src/pull/946
Can you review it and merge it please ?
Best regards.
--
Kévin Dunglas
http://dunglas.fr
http://les-tilleuls.coop
I've published a patch for bug #65576 :
https://github.com/php/php-src/pull/946
Can you review it and merge it please ?
Are we sure that's that correct behavior? Can you provide some
rationale for why it should happen this way?
--
PHP Internals - PHP Runtime Development Mailing List
To
I've just implemented what it's described in the linked bug (not my report
but my team has the same issue): https://bugs.php.net/bug.php?id=65576
The rationale is: it works the same way for all magic methods except for
the constructor and it seems to be a regression introduced in the fix of
I'm not against the patch, I'm actually indifferent.
Lets wait for Nikita's opinion.
I took just a quick look over static class RFC.
I'll need to think more about it.
Thanks. Dmitry.
On Mon, Dec 8, 2014 at 5:18 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Dmitry,
As I
On 03/12/14 10:22, Anatol Belski wrote:
I meant that as well, to the time it's merged all the TSRMLS_* thingies
should be removed. I kept them only while developed and now for the RFC so
the diff shows the only change done, otherwise it would sink in the
unrelevant stuff.
Therefore I'd rather
On Mon, Dec 8, 2014 at 11:45 AM, Dmitry Stogov dmi...@zend.com wrote:
I don't see technical problems with the patch.
However, I also don't see any significant benefits.
From the user perspective it'll just change error messages and prevent
final final class declarations.
Nikita, what do you
Nikita,
Shouldn't #3 make more sense taking into consideration this commit:
https://github.com/guilhermeblanco/php-src/commit/872a97c8dbc1c8823985d9a0305938c508865a0d
It is part of a followup PR https://github.com/php/php-src/pull/937 that
removes compiler code checks and delegates to bison,
Good evening,
I’m opening voting on the Unicode Codepoint Escape Syntax RFC. There’s been
some discussion in the last two weeks since I introduced the RFC, but there’s
nothing left which I feel needs changing. For the character name syntax
suggestion (i.e. something like \N{arabic letter
On Mon, Dec 08, 2014 at 11:51:37PM +, Andrea Faulds wrote:
Good evening,
I’m opening voting on the Unicode Codepoint Escape Syntax RFC. There’s been
some discussion in the last two weeks since I introduced the RFC, but there’s
nothing left which I feel needs changing. For the character
Hi Alain,
On 9 Dec 2014, at 00:11, Alain Williams a...@phcomp.co.uk wrote:
I vote 'yes’.
At the risk of stating the obvious: I don’t see your vote on the page’s voting
widget. Please vote there.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing
thanks for the rfc! Maybe you can add to the documentation that older PHP
versions can use json_decode with the limit to 4 hex digits:
php -r echo json_decode('\man\u0303ana\');
php -r echo json_decode('\ma\u00F1ana\');
Regards
Thomas
Andrea Faulds wrote on 09.12.2014 00:51:
Good evening,
On Tue, Dec 09, 2014 at 12:38:54AM +, Andrea Faulds wrote:
Hi Alain,
On 9 Dec 2014, at 00:11, Alain Williams a...@phcomp.co.uk wrote:
I vote 'yes’.
At the risk of stating the obvious: I don’t see your vote on the page’s
voting widget. Please vote there.
I looked ... I now see
2014-12-09 0:51 GMT+01:00 Andrea Faulds a...@ajf.me:
https://wiki.php.net/rfc/unicode_escape
Still leaves unmentioned that there was already an established Unicode
escape syntax. PCRE provides \x{1F520} for codepoints in conjunction to
plain \xFF for byte escapes.
Maybe there should be more
Hi!
On 9 Dec 2014, at 02:14, ma...@include-once.org wrote:
2014-12-09 0:51 GMT+01:00 Andrea Faulds a...@ajf.me:
https://wiki.php.net/rfc/unicode_escape
Still leaves unmentioned that there was already an established Unicode
escape syntax. PCRE provides \x{1F520} for codepoints in
Hey:
On Mon, Dec 8, 2014 at 7:15 PM, Andrea Faulds a...@ajf.me wrote:
On 8 Dec 2014, at 08:22, Xinchen Hui larue...@php.net wrote:
the current warning message is : expects parameter 1 to be long,
double given in %s on line %d
but maybe it should be something like: expects parameter 1 to be
Tue, 9 Dec 2014 02:44:33 + Andrea Faulds a...@ajf.me:
Well, PCRE does what it does probably because of its name:
*Perl-Compatible* Regular Expressions. Perl has the \x syntax. But
PCRE’s syntax comes from what suits Perl, not PHP, so I don’t see why
we should necessarily match its
23 matches
Mail list logo
