Re: [PHP-DEV] [VOTE] PHP Technical Committee

On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka wrote: > Hi, > > The vote is now open for the RFC about introduction of the PHP Technical > Committee: > > https://wiki.php.net/rfc/php_technical_committee > > Regards > > Jakub > Hi Jakob. Sorry for not participating in the discussion phase but I

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

On Wed, Sep 2, 2020 at 7:41 PM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > do you have anything against updating PHP to pass "instance before > cloned" to any __clone call from php? > Yes, I think that allowing the original object to be modified by a cloning operation could be

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

Hi Derick, I'd like to reinforce the idea that this RFC (as all RFCs) needs a Yes/No primary vote which should attain a 2/3 majority to pass. As it was the case with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary vote asking "Are you okay with re-voting on the attribute

[PHP-DEV] Re: [VOTE] Remove inappropriate inheritance signature checks on private methods

Hi internals, I'm glad to inform you that the RFC has been accepted with 24 votes for and 11 votes against. https://wiki.php.net/rfc/inheritance_private_methods I'll add some notes to UPGRADING on the PR and hope to get a new review of the implementation before merging it. Thank you again to

Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature checks on private methods

On Fri, Jun 19, 2020 at 10:17 AM Nikita Popov wrote: > On Tue, Jun 16, 2020 at 11:19 AM Marco Pivetta wrote: > >> Maybe the magic methods would indeed all need to respect `final`, and we >> haven't considered all scenarios? >> > > Or ... we could just not change this part of the behavior at all

Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature checks on private methods

On Tue, Jun 16, 2020 at 10:19 AM Marco Pivetta wrote: > On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov > wrote: > >> The original RFC could at least >> make a consistency argument, but the final form, which converts an >> existing >> special case into an even more convoluted special case, can

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

On Mon, Jun 15, 2020 at 10:41 PM Deleu wrote: > People arguing BC breaks without even knowing the scope of the change > clearly show biased. > Bold assumption there. There is at least one PR suggesting similar changes and you can gauge the amount of BC based on it. Unless "blacklist" is not

[PHP-DEV] [VOTE] Remove inappropriate inheritance signature checks on private methods

Hi internals, I have opened the vote on the "Remove inappropriate inheritance signature checks on private methods" RFC. Which can be found here: https://wiki.php.net/rfc/inheritance_private_methods The voting period will end on 2020-06-29 22:00 UTC. Thanks to those who participated in the

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

On Wed, May 27, 2020 at 12:07 AM Pedro Magalhães wrote: > On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote: > >> Considering that, as far as I know, only the constructor remains >> "special". >> > > Leaving the special case only for constructors inst

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

On Wed, May 27, 2020 at 8:23 AM Alexandru Pătrănescu wrote: > In terms of what final does to a private method, as I understand, it will > just be ignored everywhere? (except for constructor) > I mean, final deny overriding but private methods cannot be overridden by > design. We should have that

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote: > Considering that, as far as I know, only the constructor remains "special". > Leaving the special case only for constructors instead of all magic methods sounds better to me. Right now, that sounds like a winning compromise for the RFC. It

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

that goal is equally possible to achieve with final protected. Regards, Pedro On Fri, May 22, 2020 at 5:25 PM Marco Pivetta wrote: > Hey Pedro, > > On Fri, May 22, 2020 at 5:43 PM Pedro Magalhães wrote: > >> Hi internals, >> >> I want to put up for discussion an RFC

[PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

en up that exception for magic methods, for the sake of clarity maybe we should just keep the "final private" behavior on all methods and just change the static and the abstract behaviors. Some discussion on this subject can be found on the PR ( https://github.com/php/php-src/pull/5401)

Re: [PHP-DEV] [VOTE] Server-Side Request and Response Objects (v2)

Hi, To justify my "no" vote. I agree that it would be nice if PHP would provide these objects out of the box, but there are some inconsistencies in the object properties that made me oppose this. For instance, not all headers are treated equally, while some become properties of the request

Re: [PHP-DEV] Are PECL modules preferable?

On Mon, Mar 23, 2020 at 4:03 PM Mike Schinkel wrote: > Once a managed host has a working platform they are loath to change it > because something might break and create dogged wntime for their customers > that is potentially devastating for their business. > > Thus managed hosts rarely add

Re: [PHP-DEV] Alternative approach to short tags deprecation

On Thu, Apr 25, 2019 at 8:15 AM Nikita Popov wrote: > Any website using short_open_tags without explicitly > enabling it (relying on the default) will leak source code unless proper > precautions are taken before switching to PHP 7.4. > > In PHP 7.4: > * The default value of short_open_tag

Re: [PHP-DEV] [RFC] Nullable Casting

On Mon, Apr 8, 2019 at 6:05 AM David Rodrigues wrote: > Current solution: > > $itemsPerPage = Input::get('itemsPerPage') ?: null; > $itemsPerPage = $itemsPerPage !== null ? (int) $itemsPerPage : null; > > $paginator->setItemsPerPage($itemsPerPage); // OK > > With this new feature: just... > >

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi, Regarding the definitions of what constitutes a Change, a Packaging Decision and an Implementation Decision, I think it does a better job than the current voting RFC but IMHO it still is over-complicated. Trying to specify which changes are which just for the sake of allowing some things to

Re: [PHP-DEV] Exposing the linux namespaces API via pcntl_*

On Wed, Jan 23, 2019 at 10:05 PM Rowan Collins wrote: > On 23/01/2019 21:15, Pedro Magalhães wrote: > > I think it can be useful for a language to expose this functionality to > the > > users for that kind of purpose (ie. run a security sensitive task in > > iso

[PHP-DEV] Exposing the linux namespaces API via pcntl_*

Hi internals, Linux namespaces have been around for a long time and in recent years their usage has increased dramatically with the popularization of containers. Modern browsers also make use of them to sandbox certain processes and so on. To quote an introduction to the subject: The purpose of

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

On Thu, Sep 20, 2018 at 12:50 PM Rowan Collins wrote: > Encouraging people to use them gives them a false guarantee, and allowing > them to do so prevents us adding a stricter version of the feature later. > What exactly would prevent us from enforcing it in the future? The way I see it,

Re: [PHP-DEV] Re: setcookie() doesn't follow the RFC in 7.3

On Thu, Sep 20, 2018 at 12:12 PM Christoph M. Becker wrote: > The SameSite cookie attribute support has been documented[1], and an > errata section has been added to the RFC[2]. > > [1] > [2] > < >

Re: [PHP-DEV] Status of ci.qa.php.net?

On Fri, Aug 10, 2018 at 12:19 PM Christoph M. Becker wrote: > On 01.08.2018 at 20:29, Pedro Magalhães wrote: > > If anyone finds some value in having something like this and wishes to > > revive our instance, I'd be glad to help setting it up. If we feel that > > Travis

[PHP-DEV] Re: On abstract methods defined on traits

On Fri, Aug 3, 2018 at 7:22 PM Christoph M. Becker wrote: > On 03.08.2018 at 19:08, Pedro Magalhães wrote: > > What currently happens is that (like with normal methods), the method on > > the receiving class is used and the method from the trait is simply > ignored.

Re: [PHP-DEV] bugs.php.net downtime

On Fri, Aug 3, 2018 at 6:44 PM Gabriel Caruso wrote: > Pedro > > This was previously reported as a bug > https://bugs.php.net/bug.php?id=76079. > I knew I had read about it somewhere! There it is. Thanks!

Re: [PHP-DEV] bugs.php.net downtime

Hi Rasmus, I'm not able to attach a PR to a bug report, however I'm not sure if this wasn't already happening before the migration. When submitting the form, I get a 500. Thanks, Pedro On Tue, Jul 17, 2018 at 9:38 PM Rasmus Lerdorf wrote: > I need to move bugs.php.net to another server

[PHP-DEV] On abstract methods defined on traits

Hi internals, On the documentation about traits there is a mention to: "Traits support the use of abstract methods in order to impose requirements upon the exhibiting class." in https://secure.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.abstract However, this is not true, and

Re: [PHP-DEV] Status of ci.qa.php.net?

On Mon, Jul 30, 2018 at 1:44 PM Christoph M. Becker wrote: > On 28.07.2018 at 13:04, Ferenc Kovacs wrote: > > > On Thu, Jul 26, 2018 at 11:34 AM, Christoph M. Becker > > > wrote: > > > >> refers to , but the latter > >> appears to be unavailable. It

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

On Sun, Jul 22, 2018 at 6:54 PM Andrey Andreev wrote: > Last, but certainly not least, we talk about $expires here only becase > that's how it's (currently) named in either documentation and/or > reflection. But for all intents and purposes it may as well be named > $fooBar and it wouldn't

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller wrote: > It'd be great to use an OO approach instead of "magic" array keys, > e.g. like this: > > https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php > > Regards, Niklas > Hi, While I do agree

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

On Sun, Jul 22, 2018 at 1:16 PM Andrey Andreev wrote: > Ok, I can see how it can be inconvenient for > session_set_cookie_params(), though calling it "extremely" unfriendly > is some exaggeration IMO. Hi, Right, I may have been a bit overly dramatic. :) > But while I didn't quote that part

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev wrote: > Yes. > > All other "options" are actual *cookie attribute* names, as defined by > the various IETF RFCs, while "lifetime" is just a convenient name used > by PHP. It doesn't correspond to a particular attribute, but instead > the values

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

On Sat, Jul 21, 2018 at 12:11 PM Christoph M. Becker wrote: > Personally, I'd even prefer this, but that's not what was voted upon, so > I'm not sure if it's okay. Anyhow, the implementation is available as > . Thanks, Pedro! > I personally believe

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

On 28-08-17 21:06, Stanislav Malyshev wrote: > Something not clear to me on the second one - why lifetime/expiration is > a separate parameter while all others are part of $options? On Mon, Aug 28, 2017 at 8:53 PM Frederik Bosch wrote: > 1. The session_set_cookie_params function requires a

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei wrote: > I don't think we have an agreement on dealing with non-existing value, and > the way this RFC proposed, just returning null without any notice/warning, > is wrong IMO. I know we already do this in other array_* functions, but we > cannot keep

Re: [PHP-DEV] [RFC] Typed Properties

On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote: > I've also given several examples - some of them arguably quite bigger than > this proposal - where we sat on code for a very long time (multiple years > even) in order for it to be included in a major version, and not a minor > one (phpng,

Re: [PHP-DEV] [RFC][Vote] iterable_to_array() and iterable_count()

On Tue, Jul 3, 2018 at 9:48 PM Michael Moravec wrote: > Hello internals, > > The RFC for adding iterable_to_array() and iterable_count() is now open for > voting: > > https://wiki.php.net/rfc/iterable_to_array-and-iterable_count > > You can vote for each function separately. > > Voting will

Re: [PHP-DEV] Strict switch statements

> > switch($a){ >case true: > //will match true, 1, etc... > break; >strict case false: > //will not match anything except boolean FALSE > //other stuff > break; >case false: > //will match 0, null, etc > break; > } > I like this syntax, but

Re: [PHP-DEV] Better types without runtime checking

On Fri, Jun 8, 2018 at 1:28 PM Rowan Collins wrote: > On 8 June 2018 at 10:22, Nikita Popov wrote: > > > > > FTR, Bob and me plan to bring this RFC back up for PHP 7.3 soon, with > > support for static properties and for references. A mostly finished > > implementation has been lying around

Re: [PHP-DEV] Re: [PHP-DOC] Re: Ambiguity in the oop5 visibility docs

On Sat, May 26, 2018 at 3:04 PM, Rowan Collins wrote: > > Note that this example also works in Java: https://tio.run/##vZMxb9swEIVn > 61fcKKctbWctMhUIuhgomqIdigwn8mIxpUiDPNkpDP92hxJlW4rsIUBRQhP5 > @O670@MzbvDTs/pzOGAR2KNkkAZDgG9eS4JdBnGtvWOSTAqUqwtDsEFT0@f2 >

Re: [PHP-DEV] Re: [PHP-DOC] Re: Ambiguity in the oop5 visibility docs

On Fri, May 25, 2018 at 6:47 PM, Rowan Collins wrote: > > I'm not sure what exactly is "ambiguous" or "might change" here. The > current text accurately describes what "protected" means in PHP, and in > many other languages: a property which may be accessed only within

[PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

Hi internals, I'm happy to announce that the RFC was accepted with 17 votes for and 2 against. The secondary vote about introducing a deprecation notice on 7.3 was rejected. I have moved the RFC to a new section for accepted PHP 8.0 RFCs under the Pending Implementation section. You can find the

Re: [PHP-DEV] Traits with interfaces

On Thu, Mar 1, 2018 at 11:04 PM, Rowan Collins wrote: > > What *can* break an interface's contract is changing the *visibility* of > the pasted method using "as protected" or "as private". This would need to > be captured somehow while composing the class, probably

[PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

Hi internals, After fixing some issues with the deprecation notice, this RFC is ready for the voting period. There are two separate votes in this RFC and both require a 2/3 majority: - Introduce the new behavior in 8.0 - Introduce a deprecation notice in 7.3 You can find the RFC on:

Re: [PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

On Mon, Feb 26, 2018 at 5:25 PM, Pedro Magalhães <m...@pmmaga.net> wrote: > > Hi Nikita, thanks for the feedback. > > About the implementation of the deprecation notice, I agree that it should > be updated to be exception-safe. > Hi internals, Just to give you an upda

Re: [PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

On Mon, Feb 26, 2018 at 1:05 PM, Nikita Popov wrote: > > > I like the change, but I'm concerned about the technical impact that > deprecation notice will have. An error handler can convert the notice into > an exception, which means that zend_hash_next_index_insert is now

Re: [PHP-DEV] Re: [RFC] [Discussion] Arrays starting with a negative index

Hi Niklas, On Thu, Feb 22, 2018 at 8:38 PM, Niklas Keller wrote: > Hey, > > "Will no longer produce any output." in the BC example is wrong, it > will produce a notice due to an undefined index then. > > That's right. I've updated the RFC to make that section more clear.

[PHP-DEV] Re: [RFC] [Discussion] Arrays starting with a negative index

On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães <m...@pmmaga.net> wrote: > Hi internals, > > I want to bring up this RFC once again given that now seems to be the > right timing for it. I have previously canceled the vote when I initially > proposed this to land on 7.2 whic

[PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

period starts. Looking forward for any feedback. Regards, Pedro Magalhães

Re: [PHP-DEV] unit test a single case

On Wed, Jan 17, 2018 at 4:50 PM, Nikita Popov wrote: > On Wed, Jan 17, 2018 at 5:40 PM, Sam Ding wrote: > > > > > Hi PHP developers, > > > > I am new and try to porting php v7.2.1 on IBM s390x, after building and > > run unit test "make test", there

Re: [PHP-DEV] Outstanding php.net account requests

On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter wrote: > Hi, > > we currently have 118 outstanding php.net account requests going back > to October 2016. If you recently tried to onboard somebody could you > verify whether they are still unapproved? If somebody creates

Re: [PHP-DEV] Re: PHP's mail servers suck

I'm not sure if the people who have access to the machines follow this mailing list as well, so I would suggest reaching out directly to the people listed as having access to the mailing lists machine (you can find that list here: https://wiki.php.net/systems/pb1). Also, there seems to be a

Re: [PHP-DEV] Strict type declarations not enforced for Reflection API invocation

On Tue, Oct 10, 2017 at 5:53 PM, Nikita Popov wrote: > > The problem are not internal function calls, the problem are callbacks. In > fact, the proposed fix does not actually fix the problem you encountered in > PHPUnit, as it is going to use the strictness mode at the

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins wrote: > > The short form is still constrained to be a single expression, because > otherwise you can't omit the "return" statement; For the sake of discussion, Groovy has optional returns where the last evaluated

[PHP-DEV] [RFC] [VOTE] Restarted vote on the negative arrays

Hi internals, Based on the feedback on the original RFC targeting 7.2, I have now updated the RFC to target version 8.0. Additionally, I changed the existing PR to throw a E_DEPRECATED notice on the cases where this RFC will cause a BC break when the change is implemented to ease the detection of

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

On Thu, Jun 8, 2017 at 9:52 AM, François Laupretre wrote: > > I am sorry you take it this way. Voting today on a feature for 8.0 > wouldn't be ridiculous and it would make me change my vote, as most others. > Instead of nonsense, it would be a sign of maturity for the PHP

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

On Wed, Jun 7, 2017 at 2:41 PM, François Laupretre wrote: > > So, I respectfully ask you to change target to PHP 8 or explain why we > should make an exception to the process. Reasons you gave so far are OK for > a major version, but not for a minor one. This is not against

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 7 June 2017 15:23:13 BST, "Pedro Magalhães" <m...@pmmaga.net> wrote: > >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins <rowan.coll...@gmail.com> > >wrote: > > > &

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins wrote: > you can't simply pass something that *incidentally* changes a > pre-established rule Hi Rowan, Would you consider that that is not the case for your own RFC? https://wiki.php.net/rfc/deprecate-bareword-strings

[PHP-DEV] In case your e-mail client did not start a new thread

Sorry for the second e-mail but to ensure your e-mail client starts a new thread, this serves as the announcement the I have opened the "Arrays starting with a negative index" RFC for voting. You can find the RFC here: https://wiki.php.net/rfc/negative_array_index The vote will be open until

[PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

Hi all, I have just opened the vote on this RFC. The main goal of the RFC is to eliminate the inconsistency in arrays when negative numeric keys are used explicitly and the following implicit keys will start from zero. You can find the RFC here: https://wiki.php.net/rfc/negative_array_index The

Re: [PHP-DEV] Re: [RFC] [Discussion] Arrays starting with a negative index

On Tue, Jun 6, 2017 at 7:22 PM, Sara Golemon <poll...@php.net> wrote: > On Tue, Jun 6, 2017 at 7:06 AM, Pedro Magalhães <m...@pmmaga.net> wrote: > > Given that I got no more feedback on this, I'm ready to move it to > voting. > > However, before doing so, I would l

[PHP-DEV] Re: [RFC] [Discussion] Arrays starting with a negative index

On Sun, May 21, 2017 at 5:29 PM, Pedro Magalhães <m...@pmmaga.net> wrote: > Hi all, > > I have previously discussed this topic here and I have now created an RFC. > The main goal of the RFC is to eliminate the inconsistency in arrays when > negative numeric key

[PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

://wiki.php.net/rfc/negative_array_index The previous discussion: https://externals.io/thread/712 And the PR (also some discussion): https://github.com/php/php-src/pull/2383 I also have left the target version as an open issue in case most people would prefer not to do it in a "minor" version. Rega

Re: [PHP-DEV] Re: On arrays starting with a negative index

Hi Rowan, On Sat, Mar 4, 2017 at 5:09 PM, Rowan Collins wrote: > > I haven't built with the patch to check, but have you checked it behaves > correctly with other combinations? For instance [-10 => true, -5 => true, > true] or ['string_key' => true, -10 => true, true]

Re: [PHP-DEV] Re: On arrays starting with a negative index

Hi Rowan, On Thu, Mar 2, 2017 at 11:39 PM, Rowan Collins wrote: > > Would other behaviour also be affected? > > For instance: > > $foo = [ -2 => true ]; > $foo[] = true; > $foo[] = true; > var_dump($foo); > > If so, this is a much wider BC break; if not, why not? > It

[PHP-DEV] Re: On arrays starting with a negative index

On Wed, Feb 15, 2017 at 7:28 PM, Pedro Magalhães <m...@pmmaga.net> wrote: > Hi internals, > > I've prepared a PR (https://github.com/php/php-src/pull/2383) that would > change the current behavior of arrays when the first index is a negative > integer. > > The main

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

Hello all, The voting has been closed and the RFC is declined with 19-13 which is not enough for the 2/3 required majority. Thank you all for voting and for participating in the discussion. Regards, Pedro

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

> > > Too bad it has been rejected. > The vote is still open until the 20th. Regards, Pedro

[PHP-DEV] On arrays starting with a negative index

integer. However, the current (and historical) result is properly documented on the array_fill page. I would like to hear your feedback about this change and if you feel this warrants an RFC. Best regards, Pedro Magalhães

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

On Wed, Feb 15, 2017 at 2:11 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > On 15.02.2017 at 13:52, Zeev Suraski wrote: > > >> -Original Message- > >> From: Dan Ackroyd [mailto:dan...@basereality.com] > >> Sent: Tuesday, February 14, 2

Re: [PHP-DEV] Re: [RFC][VOTE] Binary String Deprecation

Hi Nikita, The deprecation notice is not thrown during token_get_all() calls. Regards, Pedro On Fri, Feb 3, 2017 at 2:00 PM, Nikita Popov <nikita@gmail.com> wrote: > On Fri, Feb 3, 2017 at 1:53 PM, Pedro Magalhães <m...@pmmaga.net> wrote: > > > Sorry, I mi

[PHP-DEV] Re: [RFC][VOTE] Binary String Deprecation

Sorry, I missed the link to the RFC on the previous e-mail: https://wiki.php.net/rfc/binary_string_deprecation Best regards, Pedro Magalhães

[PHP-DEV] [RFC][VOTE] Binary String Deprecation

Hello internals. After a *very* quiet period of discussion, I have now opened the vote for the Binary String Deprecation. There is a single vote for accepting or rejecting the deprecation. The voting phase will end on 2017-02-20 20:00 UTC. Best regards, Pedro Magalhães

[PHP-DEV] [RFC][Discussion] Binary String Deprecation

or the implementation patches. Best regards, Pedro Magalhães

[PHP-DEV] Wiki RFC karma request: pmmaga

Hi all, In order to create the RFC for the deprecation of the binary strings and future RFCs, I kindly request that my account on the wiki (pmmaga) is given the necessary karma. Thanks in advance. Regards, Pedro Magalhães -- PHP Internals - PHP Runtime Development Mailing List

[PHP-DEV] Re: Binary string forward compatibility removal

On 2016-11-06 20:22, Pedro Magalhães wrote: Hi internals, I've created a PR (https://github.com/php/php-src/pull/2187) aiming at the removal of the binary string forward compatibility. Reproducing the description of the PR: In version 5.2.1, the b prefix and the (binary) cast were

[PHP-DEV] Binary string forward compatibility removal

this into an RFC if you think it would be appropriate. Any feedback would be greatly appreciated. Best regards, Pedro Magalhães -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php