2014-11-24 6:29 GMT+01:00 Xinchen Hui :
> I don't understand why you rush for it. any work of you depends the
> number bumping?
I don't see what makes it so different that we cannot do it now
instead of later, not like it will be a game changer
+1 for the change
--
regards,
Kalle Sommer Nie
On Mon, Nov 24, 2014 at 10:24 AM, Kalle Sommer Nielsen
wrote:
> 2014-11-24 6:29 GMT+01:00 Xinchen Hui :
> > I don't understand why you rush for it. any work of you depends the
> > number bumping?
>
> I don't see what makes it so different that we cannot do it now
> instead of later, not like it w
I like the last patch. I think ZEND_ACC_STATIC flag must not make any
problems.
However, I thought about one more inconsistent. Your patch works fine for
"parent::" methods but not for "grandparents::"
In the following code "default constructor" won't work.
class A {
}
class B extends A {
}
class
On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds wrote:
> Good evening,
>
> Since phpng, int64, and perhaps other future changes in PHP 7 are a pretty
> big change, I think we ought to bump the major version number of the Zend
> Engine, from Zend Engine 2 to Zend Engine 3.
>
> I have a pull request
On 24 Nov 2014 12:18, "Nikita Popov" wrote:
>
> On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds wrote:
>
> > Good evening,
> >
> > Since phpng, int64, and perhaps other future changes in PHP 7 are a
pretty
> > big change, I think we ought to bump the major version number of the
Zend
> > Engine, fr
On 24 Nov 2014 12:32, "Paul Dragoonis" wrote:
>
>
> On 24 Nov 2014 12:18, "Nikita Popov" wrote:
> >
> > On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds wrote:
> >
> > > Good evening,
> > >
> > > Since phpng, int64, and perhaps other future changes in PHP 7 are a
pretty
> > > big change, I think w
On 11/23/2014 2:47 PM, Rowan Collins wrote:
For JSON, newlines aren't the delimiter you want, but with nested structures,
I'm not sure how you'd parse a partial structure anyway. Are there JSON
equivalents of SAX (event-based) parsers?
If JSON is encoded into another format, newlines can be a
On Mon, Nov 17, 2014 at 10:25 AM, Dmitry Stogov wrote:
> Hi,
>
> Please review the patch
> https://gist.github.com/dstogov/47a39aff37f0a6441ea0
>
> Thanks. Dmitry.
>
Hi Dmitry, sorry for late reply.
The problem we're trying to solve here is lack of ability to create a
zend_string at compile tim
Hi Nikita,
Thanks for review. I already thought about both approaches and failed as
well (the second also doesn't work with C++).
The proposed patch doesn't complicate engine a lot (may be only the
inheritance code), but I afraid about problems in some edge cases.
Thanks. Dmitry.
On Mon, Nov 24,
Dmitry Stogov wrote on 24/11/2014 09:56:
However, I thought about one more inconsistent. Your patch works fine for
"parent::" methods but not for "grandparents::"
In the following code "default constructor" won't work.
class A {
}
class B extends A {
}
class C extends B {
function __construct
Le Wed Nov 19 2014 at 10:57:39 PM, Levi Morrison a écrit :
>
> - PHP suffers a lot from function bloat and this RFC provides
> multiple functions that do the same thing but differ only in how they
> handle errors. A simple validation of "can this be safely cast to an
> integer without dataloss?"
> On 24 Nov 2014, at 16:08, Patrick ALLAERT wrote:
>
>
> Le Wed Nov 19 2014 at 10:57:39 PM, Levi Morrison a écrit :
> - PHP suffers a lot from function bloat and this RFC provides
> multiple functions that do the same thing but differ only in how they
> handle errors. A simple validation of
Hi!
> However, I thought about one more inconsistent. Your patch works fine
> for "parent::" methods but not for "grandparents::"
> In the following code "default constructor" won't work.
Yes, this is OK - the support is only for one pattern, calling the
parent, because it's what you're supposed
On 23 November 2014 23:36:30 GMT, Bill Salak wrote:
>The callback would be given the string as returned by fgets today. The
>functional equivalent to fgetjson today is handled by something like
>$handle = fopen(~some file~, 'r');
>while (($data = fgets($handle)) !== FALSE) {
>$data = json_dec
Internals folks--
Who owns Zend Opcache these days? I've got a crash dump that appears to be a
double-free of ZCG(cwd) during accel_chdir on PHP 5.5.18.
Does this crash look familiar to anyone?
[windbg output]
0:000> .ecxr
eax= ebx=01b47cb0 ecx=77b12240 edx=01b0 esi=01b12f08 edi=
Good evening,
Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
It has a rationale section explaining why certain decisions were made, that I’d
recommend you read in full.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
> On 24 Nov 2014, at 22:09, Andrea Faulds wrote:
>
> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
My apologies to you all, a small correction: The title of that email should’ve
been “[RFC] Unicode Codepoint Escape Syntax” to match the title of the RFC, I
missed out the “Codepoint
On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds wrote:
> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
>
I'm okay with producing UTF-8 even though our strings are technically
binary. As you state, UTF-8 is the de-facto encoding, and recognizing
this is pretty reasonable.
You may want
> On 24 Nov 2014, at 22:21, Sara Golemon wrote:
>
> On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds wrote:
>> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
>>
> I'm okay with producing UTF-8 even though our strings are technically
> binary. As you state, UTF-8 is the de-facto encod
On 24 November 2014 at 14:21, Sara Golemon wrote:
> On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds wrote:
>> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
>>
> I'm okay with producing UTF-8 even though our strings are technically
> binary. As you state, UTF-8 is the de-facto encoding
> On 24 Nov 2014, at 22:30, Adam Harvey wrote:
>
> On 24 November 2014 at 14:21, Sara Golemon wrote:
>> On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds wrote:
>>> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
>>>
>> I'm okay with producing UTF-8 even though our strings are technica
On 24 November 2014 at 14:35, Andrea Faulds wrote:
>
>> On 24 Nov 2014, at 22:30, Adam Harvey wrote:
>> I'm also OK with this, although I do wonder if we should be respecting
>> the user's default_charset setting instead. (Since default_charset
>> defaults to "UTF-8", in practice this isn't a sig
> We would have to require ICU, but that might be worthwhile for PHP 7
> anyway. Having at least one i18n API that's guaranteed to be available
> would be nice.
>
It's 2014. I think requiring ICU is reasonable at this point.
Orthogonal to this RFC, but I'd be in favor of deprecating all the
non-I
> On 24 Nov 2014, at 23:19, Sara Golemon wrote:
>
>> We would have to require ICU, but that might be worthwhile for PHP 7
>> anyway. Having at least one i18n API that's guaranteed to be available
>> would be nice.
>>
> It's 2014. I think requiring ICU is reasonable at this point.
I also think
On Mon, Nov 24, 2014 at 02:21:37PM -0800, Sara Golemon wrote:
> On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds wrote:
> > Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
> >
> I'm okay with producing UTF-8 even though our strings are technically
> binary. As you state, UTF-8 is the de-f
> On 24 Nov 2014, at 23:29, Alain Williams wrote:
>
> There is a big difference with \u or \U and \x or \o and that is the number of
> characters that follow the escape. \x has 2, \o has 3 - both are short and
> easy
> to count with the eye. \U012345 is quite long and it is not so visually
> o
On Mon, Nov 24, 2014 at 11:36:28PM +, Andrea Faulds wrote:
>
> > On 24 Nov 2014, at 23:29, Alain Williams wrote:
> > echo "\U{arabic letter alef}\n”;
>
> Ooh, that’s an interesting idea. I believe Perl actually has this already,
> although it uses the \N syntax:
>
> http://perldoc.perl.or
On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds wrote:
> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
>
I've linked a provisional HHVM implementation from that page.
Planning to match whatever PHP7 does, of course, but for the moment
I've added named entity support since it's being dis
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching non-oop interface).
https://wiki.php.net/rfc/intl.char
--
PHP Intern
Le 24/11/2014 23:09, Andrea Faulds a écrit :
Good evening,
Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
It has a rationale section explaining why certain decisions were made, that I’d
recommend you read in full.
Excellent RFC, thank you for this proposal.
I would suggest this tal
30 matches
Mail list logo
