Tue, 9 Dec 2014 02:44:33 + Andrea Faulds :
>
> 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 behaviour. If
Hey:
On Mon, Dec 8, 2014 at 7:15 PM, Andrea Faulds wrote:
>
>> On 8 Dec 2014, at 08:22, Xinchen Hui 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, dou
Hi!
> On 9 Dec 2014, at 02:14, ma...@include-once.org wrote:
>
> 2014-12-09 0:51 GMT+01:00 Andrea Faulds :
>>
>> 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 conju
2014-12-09 0:51 GMT+01:00 Andrea Faulds :
>
> 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 elaboration
On Tue, Dec 09, 2014 at 12:38:54AM +, Andrea Faulds wrote:
> Hi Alain,
>
> > On 9 Dec 2014, at 00:11, Alain Williams 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 that I n
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 ev
Hi Alain,
> On 9 Dec 2014, at 00:11, Alain Williams 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 List
To unsubs
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 chara
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 alef})
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, since
On Mon, Dec 8, 2014 at 11:45 AM, Dmitry Stogov 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 think?
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 st
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,
>
>
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
anothe
> 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 uns
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
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
On Mon, Dec 8, 2014 at 1:30 PM, Damien Tournoud 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, so it is fin
On Thu, Dec 4, 2014 at 1:46 AM, 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
> mix between abstract and
> On 8 Dec 2014, at 06:24, Joe Watkins 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 week, or until t
> On 8 Dec 2014, at 08:22, Xinchen Hui 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"?
>
> since
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, guilhermebla...@
Hey:
On Mon, Dec 8, 2014 at 6:03 AM, Andrea Faulds 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 far.
23 matches
Mail list logo
