Re: [PHP-DEV] PHP 5.6.4 RC1 is ready for testing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 28/11/2014 00:49, Ferenc Kovacs a écrit : > Please test it carefully, and report any bugs in the bug system. Please, especially FPM changes need our QA (see NEWS file). All regression in 5.6.3 (related to IPv6) should be fixed. So IPv4 should work

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

Hi! > We already have the single-byte versions: chr() and ord(). It's been on Not really. chr(0xA1) is a byte with value 0xA1. The function I propose would instead produce "\xC2\xA1". -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

Hi! > You mean something along the lines of JavaScript’s > String.fromCharCode (or, in ES6, String.fromCodePoint)? Yes, exactly. > One of the nice things about that function is that it can take > multiple codes. So I can do String.fromCodePoint(65, 66, 67) to get > “ABC”. Well, that is nice but

Re: [PHP-DEV] Idea: immutable class / object

Hi! > Because of for immutable objects it's not allowed to set an mutable > object as property > you can be sure the object's state will be consistent. That's the main It may be harder to achieve than you think. How exactly do you ensure they property values do not end up containing mutable value

Re: [PHP-DEV] [RFC] Abstract final classes

Hi! > By forgetting "static" in any of your declared methods, you get no parse > error and gives you 2 possibilities: > - With E_STRICT enabled: Fatal error when non-static method is being > statically called. You'll only get this at runtime, leading to potentially > error prone. Now the testabili

Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()

On Fri, 2014-11-28 at 02:13 +0100, Bostjan Skufca wrote: > Hello everyone, > > this is a proposal to add new function to PHP core: spl_object_id() > > > The story: > > Recently I was debugging some larger libraries and sorely missed a function > that would return an object ID. A functio

[PHP-DEV] Re: EX(scope) removing

Hey: On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov wrote: > Hi, > > I'm working on call/return sequence optimization. As part of this work I'm > minimizing the size of call frame (zend_execute_data) and number of > read/write operations on call/return. > > Could you please take a look into the p

Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()

Won't `$obj1 === $obj2` work for you ? On 28 November 2014 at 09:13, Bostjan Skufca wrote: > Hello everyone, > > this is a proposal to add new function to PHP core: spl_object_id() > > > The story: > > Recently I was debugging some larger libraries and sorely missed a function > that

[PHP-DEV] New function: spl_object_id() or spl_object_handle()

Hello everyone, this is a proposal to add new function to PHP core: spl_object_id() The story: Recently I was debugging some larger libraries and sorely missed a function that would return an object ID. A function called spl_object_hash() exists, but it returns identical hashes for equa

[PHP-DEV] PHP 5.6.4 RC1 is ready for testing

Hello PHP 5.6.4 RC1 is available for testing. You can download it from *http://downloads.php.net/~tyrael/ * The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can targ

Re: [PHP-DEV] EX(scope) removing

Yes, we may store EX(called_scope) in EX(This).value.ce and set another type and/or flag(s). But it shouldn't slowdown $this access in _get_obj_zval_ptr_unused() and other often used functions. If it's possible, we may try to merge, if not, it doesn't make sense. Thanks. Dmitry. On Thu, Nov 27, 2

Re: [PHP-DEV] [RFC] Abstract final classes

Ok... so if I update the RFC to be "static class", does that make everybody happy? I mainly wanna get this forward thinking trend... =) On Thu, Nov 27, 2014 at 10:49 AM, Rowan Collins wrote: > guilhermebla...@gmail.com wrote on 27/11/2014 15:34: > >> > This is true of classes intended to be stat

Re: [PHP-DEV] Idea: immutable class / object

Am 27.11.2014 um 20:47 schrieb Levi Morrison: Am 25.11.2014 um 22:26 schrieb Marc Bennewitz: Hi internals, In OOP it's a sometimes a common issue to know the state of an object and to know if it was changed respectively it it can change state. We already have such objects like DateTImeImmuta

Re: [PHP-DEV] [RFC] Native TLS

On Thu, November 27, 2014 18:03, Andrea Faulds wrote: > >> On 27 Nov 2014, at 17:01, Joe Watkins wrote: >> >> >> On Thu, 2014-11-27 at 16:44 +, Andrea Faulds wrote: >> On 27 Nov 2014, at 16:44, Andrea Faulds wrote: Hey! Would this mean we could eventually g

Re: [PHP-DEV] EX(scope) removing

On Thu, Nov 27, 2014 at 12:59 PM, Levi Morrison wrote: >> - try to merge EX(called_scope) and EX(This). Only one of them matters. > > We could use the void *ptr in a zval (or add it to the available types > in the union) and add another flag for zval type. Anyone have an > objection with that? I

Re: [PHP-DEV] [RFC] Native TLS

Anatol Belski wrote: Hi, this is a long spoken topic which is now embodied in https://wiki.php.net/rfc/native-tls . A preliminary implementation is there as well, thus we can discuss it. Regards Anatol Great! I remember myself already wondering about that years ago. +1 -- PHP Internals -

Re: [PHP-DEV] EX(scope) removing

> - try to merge EX(called_scope) and EX(This). Only one of them matters. We could use the void *ptr in a zval (or add it to the available types in the union) and add another flag for zval type. Anyone have an objection with that? -- PHP Internals - PHP Runtime Development Mailing List To unsubs

Re: [PHP-DEV] Idea: immutable class / object

> Am 25.11.2014 um 22:26 schrieb Marc Bennewitz: > >> Hi internals, >> >> In OOP it's a sometimes a common issue to know the state of an object and >> to know if it was changed respectively it it can change state. >> >> We already have such objects like DateTImeImmutable and new proposed >> objects

Re: [PHP-DEV] EX(scope) removing

Thanks. Probably, I'll commit it tomorrow. Dmitry. On Thu, Nov 27, 2014 at 9:09 PM, Matteo Beccati wrote: > Hi Dmitry, > > On 27/11/2014 18:27, Dmitry Stogov wrote: > >> Could you please take a look into the patch that removes EX(scope) >> https://gist.github.com/dstogov/5ad50d582346385d587e >>

Re: [PHP-DEV] Idea: immutable class / object

Thoughts ? Am 25.11.2014 um 22:26 schrieb Marc Bennewitz: Hi internals, In OOP it's a sometimes a common issue to know the state of an object and to know if it was changed respectively it it can change state. We already have such objects like DateTImeImmutable and new proposed objects like

Re: [PHP-DEV] EX(scope) removing

Hi Dmitry, On 27/11/2014 18:27, Dmitry Stogov wrote: Could you please take a look into the patch that removes EX(scope) https://gist.github.com/dstogov/5ad50d582346385d587e All phpt tests are passed, but I'm not completely sure about one line - https://gist.github.com/dstogov/5ad50d582346385d58

[PHP-DEV] EX(scope) removing

Hi, I'm working on call/return sequence optimization. As part of this work I'm minimizing the size of call frame (zend_execute_data) and number of read/write operations on call/return. Could you please take a look into the patch that removes EX(scope) https://gist.github.com/dstogov/5ad50d5823463

Re: [PHP-DEV] [RFC] Native TLS

> On 27 Nov 2014, at 17:01, Joe Watkins wrote: > > On Thu, 2014-11-27 at 16:44 +, Andrea Faulds wrote: >>> On 27 Nov 2014, at 16:44, Andrea Faulds wrote: >>> >>> Hey! >>> >>> Would this mean we could eventually get rid of the treaded TSRMLS_CC/DC >>> altogether? :) >> >> Treaded? Dreade

Re: [PHP-DEV] [RFC] Native TLS

On Thu, 2014-11-27 at 16:44 +, Andrea Faulds wrote: > > On 27 Nov 2014, at 16:44, Andrea Faulds wrote: > > > > > >> On 27 Nov 2014, at 15:54, Anatol Belski wrote: > >> this is a long spoken topic which is now embodied in > >> https://wiki.php.net/rfc/native-tls . A preliminary implementatio

Re: [PHP-DEV] [RFC] Native TLS

> On 27 Nov 2014, at 16:44, Andrea Faulds wrote: > > >> On 27 Nov 2014, at 15:54, Anatol Belski wrote: >> this is a long spoken topic which is now embodied in >> https://wiki.php.net/rfc/native-tls . A preliminary implementation is >> there as well, thus we can discuss it. > > Hey! > > Would

Re: [PHP-DEV] [RFC] Native TLS

> On 27 Nov 2014, at 15:54, Anatol Belski wrote: > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. Hey! Would this mean we could eventually get rid of the treaded TSRMLS_CC/DC

Re: [PHP-DEV] [RFC] Native TLS

On Thu, 2014-11-27 at 16:54 +0100, Anatol Belski wrote: > Hi, > > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. > > Regards > > Anatol > > Afternoon Anatol, w00t

[PHP-DEV] [RFC] Native TLS

Hi, this is a long spoken topic which is now embodied in https://wiki.php.net/rfc/native-tls . A preliminary implementation is there as well, thus we can discuss it. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Abstract final classes

guilhermebla...@gmail.com wrote on 27/11/2014 15:34: > This is true of classes intended to be static whether or not they are final. Allowing a "static class" would allow you to > enforce that all methods (and properties) must be static without banning users from extending it (which is a complete

Re: [PHP-DEV] [RFC] Abstract final classes

> This is true of classes intended to be static whether or not they are final. Allowing a "static class" would allow you to > enforce that all methods (and properties) must be static without banning users from extending it (which is a completely > orthogonal decision). So if I still want to not al

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

Andrea Faulds wrote on 27/11/2014 13:48: On 27 Nov 2014, at 08:22, Stanislav Malyshev wrote: Looking into this and also reading the \u{} proposal, I also thought - do we have a programmatic way of doing what \u would do? I.e. if we assume $x holds an Unicode codepoint value (i.e., an integer) d

Re: [PHP-DEV] [RFC] Abstract final classes

guilhermebla...@gmail.com wrote on 27/11/2014 14:08: > In the RFC, I think one phrase needs clarification: > > Currently, PHP developers' only resource is to create a final class with > a private constructor, leading to untestable and error prone code. > > What is "error prone" in private __const

Re: [PHP-DEV] [RFC] Abstract final classes

> In the RFC, I think one phrase needs clarification: > > Currently, PHP developers' only resource is to create a final class with > a private constructor, leading to untestable and error prone code. > > What is "error prone" in private __construct(); and how the RFC improves > the testability of s

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

> On 27 Nov 2014, at 08:22, Stanislav Malyshev wrote: > > Looking into this and also reading the \u{} proposal, I also thought - > do we have a programmatic way of doing what \u would do? I.e. if we > assume $x holds an Unicode codepoint value (i.e., an integer) do we have > a good built-in way

Re: [PHP-DEV] Popups in the cgi win binaries

On Thu, November 27, 2014 13:24, Pierre Joye wrote: > On Thu, Nov 27, 2014 at 3:12 AM, Anatol Belski > wrote: > >> On Wed, November 26, 2014 14:38, Rowan Collins wrote: >> >>> Anatol Belski wrote on 26/11/2014 11:34: >>> >>> While it might look short cut and too late for 5.5, there's ind

Re: [PHP-DEV] [RFC] Abstract final classes

guilhermebla...@gmail.com wrote on 27/11/2014 03:47: I worked on an implementation of a somehow controversial concept that exists in hack and C#: abstract final classes. https://wiki.php.net/rfc/abstract_final_class The explanation of what exactly has been implemented could perhaps be expande

Re: [PHP-DEV] [RFC] Abstract final classes

On Thu, Nov 27, 2014 at 1:43 PM, Rowan Collins wrote: > Lazare Inepologlou wrote on 27/11/2014 10:35: > > 2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com < >> guilhermebla...@gmail.com>: >> >> Hi, >>> >>> I worked on an implementation of a somehow controversial concept that >>> exists in ha

Re: [PHP-DEV] [RFC] Abstract final classes

Lazare Inepologlou wrote on 27/11/2014 10:35: 2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com < guilhermebla...@gmail.com>: Hi, I worked on an implementation of a somehow controversial concept that exists in hack and C#: abstract final classes. https://wiki.php.net/rfc/abstract_final_clas

[PHP-DEV] PowerPC64 patchs

Hi, internals! There are some PRs for supports of PowerPC64 https://github.com/php/php-src/pull/737 https://github.com/php/php-src/pull/919 https://github.com/php/php-src/pull/920 https://github.com/php/php-src/pull/921 https://github.com/php/php-src/pull/922 Anyone can review them, please? Rem

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

Stanislav Malyshev wrote on 27/11/2014 01:03: Hi! I don't know if it would make a difference here, but I wonder if it would be sensible to add an "abstain" option in votes? That way, someone who has considered an RFC but not formed a strong opinion either way could register that fact. This coul

Re: [PHP-DEV] Popups in the cgi win binaries

On Thu, Nov 27, 2014 at 3:12 AM, Anatol Belski wrote: > On Wed, November 26, 2014 14:38, Rowan Collins wrote: >> Anatol Belski wrote on 26/11/2014 11:34: >> >>> While it might look short cut and too >>> late for 5.5, there's indeed no scenario imaginable where such graphical >>> elements could be

Re: [PHP-DEV] [RFC] Abstract final classes

Hi, 2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com < guilhermebla...@gmail.com>: > Hi, > > I worked on an implementation of a somehow controversial concept that > exists in hack and C#: abstract final classes. > > https://wiki.php.net/rfc/abstract_final_class > > The example is a little bi

Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking

Levi Morrison wrote on 25/11/2014 17:08: 1. Do covariant return types; check them at definition time 2. Do covariant return types; check them at runtime 3. Do invariant return types; check them at definition time I guess there's also option 4 - do "weak invariance", as we do with para

Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking

Lazare Inepologlou wrote on 26/11/2014 10:21: * Parameter types are contravariant, otherwise they are not type sound. Yet, contravariance in general is of little interest (I cannot think of any practical example), so invariance is a good compromise. After reading the Wikipedia article, I've bee

Re: [PHP-DEV] [RFC] Abstract final classes

2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com < guilhermebla...@gmail.com>: > Hi, > > I worked on an implementation of a somehow controversial concept that > exists in hack and C#: abstract final classes. > > https://wiki.php.net/rfc/abstract_final_class > > My motivation is to further expan

[PHP-DEV] RE: [VOTE] [RFC] PHP 7.0 timeline

All, The vote will end tomorrow at noon GMT – if you’re still interested in voting, please do so before that time… Thanks, Zeev *From:* Zeev Suraski [mailto:z...@zend.com] *Sent:* Friday, November 21, 2014 10:07 AM *To:* PHP internals (internals@lists.php.net) *Subject:* [VOTE] [RFC] PH

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

Hi! >> 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/int

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

Hi! > I'm not completely against it. It's just an incomplete solution. > > echo "\u{1F602}"; // won't output 😂 if the output encoding is not UTF-8 You can always use iconv/recode to bring it to every encoding you need (provided it supports full unicode range). I see this as a readability feature