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

[Pedro Magalhães]

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 would like to
give my explanation on why I voted No.
You made a good job in distinguishing the user-facing from the technical
changes to say what can and can't be decided by the TC, but the first can't
live with the second.
Then, it allows the TC to have conversations and vote in private in matters
that until today have always been public. Of course developers are allowed
to talk to each other wherever they want, but what matters is said in
public.
"unless the provided implementation would result in introduction of new
bugs, side effects not mentioned in the RFC, significant performance
penalties not mentioned in RFC, or if there is an equivalent implementation
in progress that the TC finds more appropriate." is ample enough that it
can allow anything to be rejected.

Overall, the idea of having a group of people that developers can ask for
some guidance from is great, but that group shouldn't have any extra rights
to block anything whatsoever.

To demonstrate good faith and unequivocally show that this is not an
attempt at a power grab, it would be a nice gesture for the authors of the
RFC to include their withdrawal from ever holding a seat in the technical
council in the text of the RFC itself.

Best regards,
Pedro

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

[Pedro Magalhães]

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 the cause for a lot of confusion. If we had a proper way
to make it read-only I wouldn't mind, but as is, it doesn't sound like a
good idea.

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

[Pedro Magalhães]

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 syntax for PHP
8.0?" and that vote passed with 50 to 8.
The primary vote on this RFC could be the exact same question, but I
believe the primary vote needs to be there. Without this primary vote, we
could be enacting a change that only (with 4 options) 25%+1 voters support,
which is clearly insufficient. However, if 2/3 of the voters agree that
something needs to change, they are also accepting that the change may not
be the one they prefer.

>From the voting RFC (https://wiki.php.net/RFC/voting#required_majority):
"The primary vote of an RFC, determining overall acceptance of the
proposal, may only have two voting options and requires a 2/3 majority.
This means that the number of Yes votes must be greater than or equal to
the number of No votes multiplied by two."
On the same RFC we can also find information about the format of secondary
votes which mandates a simple majority, this should disqualify STV:
"Additionally, an RFC may have secondary votes, which are used to decide
implementation details. Such votes may have more than two voting options
and may be decided by simple plurality. This means that the voting option
with the most votes wins. If there are multiple options with the most
number of votes, it is left at the discretion of the RFC author to choose
one of them."

I'm not saying that I agree or disagree with the changes you propose, but I
think that all RFCs should follow the rules that are laid out. Those rules
were last changed by an RFC which also required a 2/3 majority (
https://wiki.php.net/rfc/abolish-narrow-margins), so if you want to change
the requirements to accept an RFC, you should propose them and they should
be accepted before proposing a RFC which does not abide to these
requirements.

Regards,
Pedro

On Tue, Aug 4, 2020 at 2:45 PM Derick Rethans  wrote:

> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an excemption from the RM Sara as per [2]:
>
> > * Shorter Attribute Syntax Change
> >- Joe/Derick - Please make sure this RFC moves along and reaches
> >  conclusion by beta3, as discussed previously.
>
>
> cheers,
> Derick
>
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

[Pedro Magalhães]

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 all who contributed to the discussion and to all who
voted.

Regards,
Pedro

>

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

[Pedro Magalhães]

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 :) If we
> acknowledge that this is definitely useful for constructors and possibly
> useful for cloning, then maybe it is useful for other things as well? I
> still haven't heard a reason *why* we would want to do this change (not the
> general change, but specifically the "private final" one).
>
> This stuff really isn't super important to me, and I'd be happy to
> sacrifice this functionality in the name of the greater good, but I
> honestly don't understand what that greater good is in this case. It seems
> like a strict loss in functionality.
>
> Regards,
> Nikita
>

Hi Nikita,

The motivations for changing the behavior of final private are the
following:
- Theoretical: Even though private members are technically inherited by
child classes, they are not overridable. You can already have public
methods in a child class with the same name as a private parent, but you
are not overriding it (if you call that method in the parent, you will use
the private method declared there. If you call it in the child, you will
use the public method declared there - https://3v4l.org/TImO8). You can
have different visibility, different signatures (thanks to a bugfix that
was actually my first contribution to PHP :) ) and the methods are
completely unrelated except that they share the name. Sharing the name
shouldn't be a reason to enforce any inheritance rules.
- Implementation: My preferred way to implement this would have been to
skip the call to `do_inheritance_check_on_method_ex` on private methods
completely, as that would make the intention very clear. The only reason
why I couldn't is the check for abstract private methods coming from
traits. And currently, the ZEND_ACC_CHANGED flag is also added there, but I
think that could be easily avoided.
- Other languages:
- Java: https://www.ideone.com/P71k8J - final has no effect when added
to a private method (
https://www.javaworld.com/article/2077399/private-and-final.html)
- C#: https://www.ideone.com/i1OtFe - In C#, for a method to be
overridable it has to be marked as virtual. In this snippet, we are not
marking it as virtual (hence it acts as final) and nothing prevents us from
declaring it in the child class.

Regards,
Pedro

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

[Pedro Magalhães]

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 not. Why is
>> __construct() exempted, but __clone() for example isn't, even though
>> similar considerations apply to it?
>>
>
> While `private final function __construct()` prevents child classes from
> making the constructor open, or accessing it (important for abstract
> types), `protected final function __clone()` achieves the same without
> having to rely on the `private` visibility modifier (
> https://3v4l.org/psR5F, for example).
>

In my opinion, the example given by Marco on the discussion thread about
sealed types is a good argument on why __construct should keep the behavior
(https://externals.io/message/110251#110255). You would need to write a lot
of convoluted code to achieve the same behavior as you currently can.

It is true that cloning is then possible from within a subtype, which is
> indeed a bit of a problem: https://3v4l.org/qupHR
>

 I don't find that problematic. If ultimately your goal is to disallow
cloning, doing it by visibility constraints is cheaper and covers 99% of
the cases but it's still possible to enforce it even for the child class by
throwing: https://3v4l.org/U1LMQ

Regards,
Pedro

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

[Pedro Magalhães]

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
supposed to be included in this change (even though it is in the title of
the OP), there will be a BC. People with different opinions doesn't mean
they are uninformed.

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

[Pedro Magalhães]

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 discussion and provided feedback.

Regards,
Pedro

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

[Pedro Magalhães]

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 instead of all magic
> methods sounds better to me. Right now, that sounds like a winning
> compromise for the RFC. It is still an exception to a rule, but one that
> can be better justified.
>
> Thanks,
> Pedro
>

I have updated both the implementation and the RFC to reflect this
exception for constructors. If no further discussion comes up, I'll open
the vote in a few days.

Regards,
Pedro

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

[Pedro Magalhães]

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 in the documentation as well, I guess.
>

Hi Alex.

Indeed, it would just be ignored. Optionally, as the other open issue of
the RFC currently proposes, we would throw a warning on those cases
precisely to warn the user that it is meaningless.
And yes, I agree that the docs should be updated to explain that explicitly.

Regards,
Pedro

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

[Pedro Magalhães]

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 is still an exception to a rule, but one that can be better
justified.

Thanks,
Pedro

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

[Pedro Magalhães]

Hi Marco,

Thanks for the feedback.

About the sealed type example, it is true that `final protected` wouldn't
achieve the same thing. But as an attempt to provide an alternative design,
wouldn't an union type of the desired children be a better choice?
I can see some usefulness in it but IMHO, it is supported by a broken
behavior, it doesn't make sense to talk about private symbol overrides.
That shouldn't be a thing.
With that said, I don't think the RFC has to be all or nothing, but we
would leave an exception behind.

About lifting the restriction only to magic methods, I don't really like
that approach. Anything that makes them more special feels like a step in
the wrong direction. If we were to lift that restriction, I would say that
it should be lifted for any method, leaving the RFC to deal only with the
static and abstract cases.

About the serialization example, I think 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 (
>> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
>> remove some inappropriate signature checks that are still done on private
>> methods. Namely, those checks are:
>>
>> - When a method has the same name as a parent's final private method
>> - When a method has the same name as a parent's static private method and
>> the child's method is non-static, or vice-versa
>> - When a method has the same name as a parent's concrete private method
>> and
>> the child's method is abstract
>>
>> I have 2 open issues on the RFC that I would like to hear some opinions
>> on.
>> - Whether or not to issue a compiler warning whenever "final private
>> function" is used, to alert the user that it will not achieve what that
>> construct is currently used for. The disadvantage of introducing it is the
>> BC break.
>> - Whether or not to make an exception to this rule for magic methods.
>> Given
>> that this is widely to restrict object instantiation and cloning, it could
>> make sense to still allow the use on those cases. However, I think that
>> the
>> similar effect that can be achieved with "final protected function" would
>> cover most of the cases. And if we open 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) for this RFC.
>>
>
> Overall, this RFC breaks some design capabilities that are within the
> language, specifically around `__`-prefixed methods in the language.
>
> For instance, I design (on purpose) sealed types as following:
>
> ```php
> abstract class Email
> {
> final private function __construct() {}
> public static function business(): Business {
> return new Business();
> }
> public static function personal(): Personal {
> return new Personal();
> }
> }
>
> final class Business extends Email {}
> final class Personal extends Email {}
> ```
>
> The above approach guarantees that no further subtypes exist for `Email`,
> other than `Business` or `Personal`, effectively forming a safe union type,
> which can only be broken by reflection.
>
> In addition to that, I often prevent serialization of types that are not
> intended to be serialized (when not final):
>
> ```php
> abstract class InMemorySecret
> {
> final private function __sleep() {}
> }
> ```
>
> Effectively, the `final` modifier applies to `private` symbols too, and
> prevents child classes from deviating from imposed design constraints.
>
> It is **intentional** for `private` symbol overrides to not compile in
> these cases.
>
> Both of the above examples only apply to special/magic methods: I can see
> and understand that for custom methods this RFC may be valid, and adding a
> further refinement to lift the restriction only on custom methods is a good
> idea.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

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

[Pedro Magalhães]

Hi internals,

I want to put up for discussion an RFC (
https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
remove some inappropriate signature checks that are still done on private
methods. Namely, those checks are:

- When a method has the same name as a parent's final private method
- When a method has the same name as a parent's static private method and
the child's method is non-static, or vice-versa
- When a method has the same name as a parent's concrete private method and
the child's method is abstract

I have 2 open issues on the RFC that I would like to hear some opinions on.
- Whether or not to issue a compiler warning whenever "final private
function" is used, to alert the user that it will not achieve what that
construct is currently used for. The disadvantage of introducing it is the
BC break.
- Whether or not to make an exception to this rule for magic methods. Given
that this is widely to restrict object instantiation and cloning, it could
make sense to still allow the use on those cases. However, I think that the
similar effect that can be achieved with "final protected function" would
cover most of the cases. And if we open 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) for this RFC.

Regards,
Pedro Magalhães

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

[Pedro Magalhães]

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 object,
others must be accessed in the headers array. And the line that divides
them seems a bit arbitrary. For instance, CONTENT_MD5 gets special
treatment in this object while it was never special in the $_SERVER
superglobal. Some other values are missing like REQUEST_TIME (it's missing
at least from the proposal and the linked README). Finally, making
decisions like overwriting method if a HTTP_X_HTTP_METHOD_OVERRIDE header
is present seem too opinionated for an object that should be more agnostic.
It does make sense, but it hides away information from the user in an
attempt to be helpful.

In conclusion, I do think PHP should offer an OOP oriented way to deal with
requests and responses, but those objects should be more consistent and
less opinionated.

Regards,
Pedro

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

[Pedro Magalhães]

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 things to their platform unless they need
> them to support their platform (like redis or new relic) or there is
> OVERWHELMING DEMAND in userland for adding them.
>

It is utterly unreasonable to expect to change what is or isn't bundled in
a project because you managed host of choice is afraid of breaking
something.
Also, as it has been said before, just because something is bundled it
doesn't mean that your managed host of choice won't disable it during
compile time.

Find a host that lets you control your PHP installation the way you need
it. Not the other way around.

Regards,
Pedro

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

[Pedro Magalhães]

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 remains as is and enabling
> short_open_tag does not generate a deprecation warning (otherwise PHP would
> warn in a default config).
>

Hi! Thanks for providing an alternative to solve this. But I'd say to
generate the deprecation notice on first use of the short tag both when the
user is relying on the default and when explicitly enabled. Although it may
be annoying that we are throwing that notice on default config, it's the
only way to warn everyone who would be affected when the default changes or
the option is removed. I'd prefer to be annoyed than the alternative.
Also, given that the notice will go away once you got rid of all your
usages of the short tag, it sounds manageable to me.

Regards,
Pedro

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

[Pedro Magalhães]

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...
>
> $paginator->setItemsPerPage((?int) Input::get('itemsPerPage')); // OK
>
> Question: why just not check if $itemsPerPage is set like:
>
> $itemsPerPage = Input::get('itemsPerPage');
>
> if ($itemsPerPage) {
> $paginator->setItemsPerPage((int) $itemsPerPage); // OK
> }
>
> Answer: because in this example we could do that (although the new solution
> is much more practical). In another case, I have a static factory method
> that depends of an ?int to be created, and I can't just skip it with an
> if() if user input is empty.
>

Hi!

I'm not a fan of the approach for a few reasons:
- First and foremost, we would introduce a cast where you can't be sure of
what you'll get back. I understand the use-case for when you want to pass
something to a nullable parameter, but if you think about this cast in
isolation, it hardly makes sense.
- Second, maybe this is particular to your example, but your are forcing
yourself to process something that the user didn't set. If your paginator
already has a sane default(15) in a property, just don't call its setter
when the user didn't ask you to. If you insist that you really want to save
LoC, just assume that 0 means "use the default" and you can use the cast in
all cases.

Regards,
Pedro

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

[Pedro Magalhães]

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 pass with a slim majority seems a wasted effort to me. As "proven" by
the currently open issues, it also misses a categorization for
administrative changes. Stating only which changes require a RFC and which
don't would be much simpler. Also, that last part about performance
degradation will also lead to unnecessary discussion if it isn't more
clearly defined (is it just the bench.php? mediawiki test suite?).

On the section about Changing the RFC, again a distinction is made between
extending the period for 1 or 2 weeks depending on what you subjectively
consider "substantial". For the sake of simplicity, I'd suggest it to be
always 1 week.

About No Discussion/Voting Periods, I think it would be simpler to just
extend the voting period to a minimum of 2 weeks. For anyone interested on
the subject, they would have 4 weeks to find out about it (2 for discussion
and 2 for voting). Maybe some people actually have more time to
contribute/participate in discussion during their holidays.

As stated before, The Eligible Voters section fails to mention its reason
to be. Lately, RFCs get around 20 to 40 votes, why do we have to reduce the
list of potential voters? To me, it seems arbitrarily hostile to newcomers
while overly protective of people that have long lost interest. In other
words, someone who has made their last contribution 10 years ago keeps
their vote while someone who fixed a bug every 2 weeks for the last year
isn't eligible. Also, the proposed measurements are subject to be "gamed"
(not squashing your commits, changes to license headers, etc..). And for
other members of the project the same problem poses, how do you measure
docs contributions? And maintaining the servers? And PECL extension
maintainers?
About FIG, it is an organization which has its own membership rules that
are subject to change at any time at its own discretion. While I truly
believe that it would be very important to provide a way to allow the users
to express their voice, doing that via an external organization doesn't
seem acceptable. Keep in mind that the current voting RFC keeps the
decision of which community members can vote in PHP's side.
To cater to an even larger audience, there could be a section on RFCs where
anyone could cast their vote so that the RFC author can also take it into
consideration but keeping it non-binding. (Or perhaps giving it a
predefined weight - 1, 3, 5 votes?)

Regards,
Pedro

On Thu, Jan 31, 2019 at 1:44 PM Zeev Suraski  wrote:

> Without further ado, an RFC that’s attempting to comprehensively solve
> many of the issues that have plagued our RFC process since it was hastily
> introduced in 2011:
>
>
>
> https://wiki.php.net/rfc/voting2019
>
>
>
> Emphasis on ‘attempting’.  I’m sure there are still a lot of holes in it
> that should be plugged before we vote on it, but instead of waiting
> indefinitely – I’d like us to start discussing it.
>
>
>
> Comments and suggestions welcome.
>
>
>
> Zeev
>
>
>
>
>
>

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

[Pedro Magalhães]

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
> > isolation, simulate certain conditions like no network access, etc..).
> For
> > that end, I've put forward https://github.com/php/php-src/pull/3760
> which
> > provides an implementation of `pcntl_unshare(int $flags): bool`. And I'm
> > looking for some feedback if anyone would oppose the introduction of this
> > function (and probably `setns` next).
> Could you give an example of how this would work in the context of a PHP
> process? Would it only make sense in a CLI context, when performing some
> kind of system task?
>

Yes, I agree it makes most sense in a CLI context. Some examples I've
thought of:
- For testing frameworks it may be useful to have CLONE_NEWNET as that
should guarantee that a test is executed without any network access;
- For some processing tasks where you may want to mount a remote drive you
can use CLONE_NEWNS to ensure that the mount doesn't affect the host;
- If you are running a daemon controlling multiple child processes you
could issue a `pcntl_unshare(CLONE_NEWPID)` before launching each one of
them so that they can't refer to each other.
- Using all the flags available together with a `chroot` would already give
you a sufficiently isolated environment where you can run some service you
don't want installed on the host.

As for setns, it would allow you to join all the namespaces of a given
process. So your PHP process can join other processes you have unshared
before (or a Docker container for that matter).

Regards,
Pedro

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

[Pedro Magalhães]

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 each namespace is to wrap a particular global system
resource in an abstraction that makes it appear to the processes within the
namespace that they have their own isolated instance of the global
resource. One of the overall goals of namespaces is to support the
implementation of containers, a tool for lightweight virtualization (as
well as other purposes) that provides a group of processes with the
illusion that they are the only processes on the system.
- from https://lwn.net/Articles/531114/

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
isolation, simulate certain conditions like no network access, etc..). For
that end, I've put forward https://github.com/php/php-src/pull/3760 which
provides an implementation of `pcntl_unshare(int $flags): bool`. And I'm
looking for some feedback if anyone would oppose the introduction of this
function (and probably `setns` next).

Regards,
Pedro

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

[Pedro Magalhães]

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, whenever that would be possible, we could get rid of the
uninitialized state.

Regards,
Pedro

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

[Pedro Magalhães]

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]
> <
> https://wiki.php.net/rfc/same-site-cookie?do=diff&rev2%5B0%5D=1537441490&rev2%5B1%5D=1537441776&difftype=inline
> >
>
> --
> Christoph M. Becker
>

Thanks! I wasn't sure about editing the RFC as the actual docs would have
it right and UPGRADING also has the right syntax. Either way, having it on
the RFC itself is helpful to clear any confusion.

Regards,
Pedro

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

[Pedro Magalhães]

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 + Appveyor are enough, that's fine too :)
>
> Well, on further consideration it seems that having our own CI would be
> nice, especially if we'd run further test suites or different
> configurations there.  On the other hand, someone would actually to have
> a look at the test results, and act on failing tests.  Any volunteers?
>
> --
> Christoph M. Becker
>

I'd say that if we want this, then it should be integrated with github and
be a third check (next to travis and appveyor). Depending on the stability,
it could be a required or an optional check. This would be better than
expecting someone to manually check it.

Regards,
Pedro

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

[Pedro Magalhães]

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.
>
> Yes.  However, if the class using the trait would not implement the
> method, a compile time error would be thrown.
>

Not really, I mean, the error you get is that you are declaring an abstract
method in a non abstract class. If the receiving class is abstract, this
works as expected (https://3v4l.org/QdHBo) and nothing is imposed on the
receiving class.
I think this is also what Levi is referring to. (Correct me if I'm wrong)


> > Although this can be fixed, I wanted your opinion on it as this would be
> > the only thing from traits that would impose anything on the receiving
> > class and conflicts with the normal precedence rules.
>
> Frankly, I don't understand what this bug report is about,
> <https://3v4l.org/38lmA> looks pretty much expected (note that the error
> message is totally different from what has been reported; there is no
> class D in the reproduce script).
>

Yes, the report is not very clear. But if we follow the docs logic,
A::values in your example should fail to compile as it doesn't have the
same signature (return type) as the method from the trait T.

Regards,
Pedro

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

[Pedro Magalhães]

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

[Pedro Magalhães]

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 sometime today. I won't be
> able to do it without a little bit of downtime as I have to stop new
> activity on the existing box, copy the DB over and then point DNS to the
> new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable for
> much longer than that.
>
> Hopefully the new box will be a bit quicker too. It is moving from PHP 5.5
> to 7.2 on faster hardware.
>
> -Rasmus
>

[PHP-DEV] On abstract methods defined on traits

[Pedro Magalhães]

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 it has never been since traits were
introduced (https://3v4l.org/tYAmu).

There is a related bug report in https://bugs.php.net/bug.php?id=75449

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.

Although this can be fixed, I wanted your opinion on it as this would be
the only thing from traits that would impose anything on the receiving
class and conflicts with the normal precedence rules.

Regards,
Pedro

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

[Pedro Magalhães]

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 seems the site was about Jenkins CI – has
> >> it been superseeded by Travis and Appveyor?  If so, qa.php.net should
> be
> >> updated.
> >
> > it was mostly managed and used by me and at one point it went down and I
> > did not had the time to contact the provider and figure out what
> happened.
> > I'm fine with being removed or if you think that it would be useful we
> can
> > try bringing it back.
>
> Thanks, Ferenc!  I think, now that we're having Travis and Appveyor,
> there's not much need for having our own Jenkins, and I think it's more
> worthwhile to actually cater to the user submitted test reports.
>
> I'll remove the ci.qa.php.net related stuff from the QA website in a few
> days.
>

Hi all,

Although travis and appveyor do most of the work, I think there is still
some value in having our own Jenkins. Namely, the ability to run other test
suites for each change in the PHP repo. IIRC, the old jenkins instance was
also running the wordpress tests for every change to PHP, which can help us
find issues earlier. I have been maintaining a Jenkins instance for PHP
that you can find in https://php-ci.pmmaga.net/ with the configuration and
pipeline definitions in https://github.com/pmmaga/php-jenkins-pipelines

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 + Appveyor are enough, that's fine too :)

Regards,
Pedro

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

[Pedro Magalhães]

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 matter as long as it is a concrete parameter,
> whereas an associative array key name is very important. Now I'd have
> to remember if it actually is "lifetime", "expire" or "expires" ... or
> is it "max-age"? Not only that, but if it is either "expires" or
> "max-age", I would rightfully have reasons to believe that the
> expected input should be match the actual Set-Cookie attribute instead
> of a PHP-specific value.
> That's very unintuitive and I believe we have a general consensus on
> this list that array parameters are somewhat evil. You have to
> remember that the only reason we're doing this here is to avoid
> parameter creep with potential for infinity, and nothing else.
>

Hi Andrey,

Well, "expires" is what ends up in the cookie header itself so I think that
it's simple to remember. But I do understand your arguments on semantic
purity and the fact that Max-Age is derived from it but I still believe
that in this case, it's not worth the distinction. If there ever comes a
new attribute that won't be used verbatim, what would we do? Leave it
between $expires and the options array and break all existing code? Leave
it to the end of the signature to avoid the BC break but then we are left
with something really awkward?

Given that we understand each other but we just disagree on what is more
important, I'd really like to hear someone else's opinion. If we are to get
something into 7.3 (which I believe we should due to
https://github.com/php/php-src/pull/2613#issuecomment-401266510) and with
the feature freeze in one week, we should reach an agreement on what to do
very soon.

Regards,
Pedro

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

[Pedro Magalhães]

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 with the sentiment:
- That would have been an even greater departure from the original RFC.
- This is currently a purely procedural API. If this were about an
hypothetical `ResponseHeaders::setCookie` it would definitely be the way to
go.

Regards,
Pedro

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

[Pedro Magalhães]

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 of your
> message, you did also suggest to apply the same decision to other
> functions and so I am talking about all of them.
>
> I'd be ok with this for session_set_cookie_params() alone, but not for
> set[raw]cookie().
>

I thought your comment was about  session_set_cookie_params only because
your reasoning about lifetime (as a relative amount of time) being a PHP
construct only makes sense there.
So I'm not sure why for set[raw]cookie the expires attribute would be
treated different from the others? Max-Age is derived from it, but the
value you pass to expires will be directly used in the cookie attribute
(although in a different datetime format). Some other attributes are also
not used verbatim. For instance, 'secure' being true or false also means
the `secure;` attribute being present or omitted.
Thinking again from the perspective of the user, I would find it annoying
to have the expires attribute separate from the others.

Regards,
Pedro

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

[Pedro Magalhães]

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 for the Expires and Max-Age attributes are derived from it.
> I believe during discussion I insisted that the parameter be called
> "attributes", for this very reason.
>

Hi,

While I do understand your reasoning, I find it extremely unfriendly to the
user of the function to ask for one parameter separate from all the others
for that reason alone.
Also, keep in mind that all this function does is set the
`session.cookie_*` ini entries. So all parameters are treated equally.


> On another note, I also wanted that pretty much any key/value pair to
> be accepted instead of raising an error, for forward compatibility.
>

I really believe that the user spotting errors like `['expries' => time() +
3600]` faster is more valuable than FC.

Regards,
Pedro

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

[Pedro Magalhães]

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 that the intent of the vote is to have this feature
and to have it included as an alternative array of parameters. I don't mean
to step on anyone's toes with the proposed implementation, but given that
the RFC doesn't define the array of options I think most people didn't
notice this design choice and/or ultimately just wanted this feature
accepted.


> > About the implementation, the array of options is never really defined in
> > the RFC. If we assume that it is identical to the proposed output
> > of session_get_cookie_params, the name of the first key should be
> lifetime.
> > However, for setcookie and setrawcookie, the documented parameter name is
> > expire. Would there be any issue if we would assume lifetime for the 4
> > functions?
>
> I'd prefer “expire_s_”, but I'm okay with “lifetime”.
>

Although I had suggested using the same key for all functions, when I
started the implementation I realized they have different meanings. For
session_get_cookie_params, lifetime is a relative amount of seconds, but
for setcookie and setrawcookie expire is an absolute timestamp. So I kept
that distinction.
About your suggestion, I looked again, and in fact, the only place where
the parameter is called expire is in the docs. Internally (ie. Reflection)
it is called expires. Given this and the fact that it is what actually is
used in the cookie header, I've changed the key to "expires".

Regards,
Pedro

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

[Pedro Magalhães]

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 lifetime parameter
> at the moment.
>
> 2. To enforce that lifetime stays required I did not want to make it
> required within the optional array. That would make that optional array
> not optional anymore, and even have a required key. I don't think that
> is a good idea.
>
> 3. To prevent that the array of options is different between the three
> functions (session_set_cookie_params, setcookie, setrawcookie), I chose
> to exclude lifetime from the array of options and include it in the list
> of arguments.
>
> Hence, I chose a consistent and logical API over the three functions
> together rather than having logical ones per function. Hope it makes sense.
>

Hi all,

This reasoning doesn't make a lot of sense to me.
With regards to session_set_cookie_params, I believe that the only reason
why lifetime is required in that function is because calling it without
parameters doesn't have a purpose.
With an array of options (which keeps the first parameter mandatory), there
is no strong reason to make one of them required. An empty array or an
array without any valid key would still error.
If this is acceptable for that function, all the other functions can have
all the options in the array as that keeps the array consistent across them.

With this being said, would anyone oppose an implementation where all the
options (including lifetime) are included in the array parameter?

About the implementation, the array of options is never really defined in
the RFC. If we assume that it is identical to the proposed output
of session_get_cookie_params, the name of the first key should be lifetime.
However, for setcookie and setrawcookie, the documented parameter name is
expire. Would there be any issue if we would assume lifetime for the 4
functions?

Regards,
Pedro

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

[Pedro Magalhães]

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 making mistakes just because we already made same mistake.
>

I voted no for the same reason. I'd even say that introducing a new array_
function that still accepts non arrays just to return null with a warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro

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

[Pedro Magalhães]

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, JIT, FFI) even though technically they could go into the next
> available minor.
>

Hi,

I'm trying to understand this argument better but there is something I'm
missing. Why would a feature like JIT (which would be transparent to the
user AFAIK) need to wait for a major other than marketing reasons?
Sorry in advance for the slightly off-topic question.

Regards,
Pedro

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

[Pedro Magalhães]

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 close on 2018-07-17 12:00 UTC.
>
>
> Thank you,
> M.
>

Hi,

I'd like to point out that a cast to array could almost replace the first
one-liner example in the RFC, with the exception of the generator case. It
may be an issue that (array)$iterator has a different behavior than
iterator_to_array($iterable) but that would be a separate discussion.

Regards,
Pedro

Re: [PHP-DEV] Strict switch statements

[Pedro Magalhães]

>
> 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 I think I'd prefer the other way around. `case
strict false:` describes better what the condition is.

Regards,
Pedro

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

[Pedro Magalhães]

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 for a while already, so we think
> it's
> > time to wrap this up and give it another try.
> >
> >
> I presume you mean 7.4, since 7.3 is in alpha already, and this is quite a
> major change?
>
> But good to hear there's still will to work on this; I shall be interested
> to hear the details of where this will take the language.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

AFAIK, alpha1 was tagged but it still didn't branch off master. That'll
only happen on July 17th. (https://wiki.php.net/todo/php73)

With that said, basically any RFC that goes to vote before July 3rd should
still be on time to make it into 7.3.

Regards,
Pedro

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

[Pedro Magalhães]

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
> LAnirpbpTt7XTDuHZnGpg2h34a7vsD/7nBhGFVfE33H7s7mVT8eVz6p75yvk
> eLPT9gBmM/iCxgTAnn9FXDoF7gm2pZYlbciDLLVR3Rx0aMFPJp649haWyKXw
> rrYqb/sa8E1HjXWYG6cVoFJ5mq7jkvy/IGyNLg36w106Exfmt8/2WZYsfuDL
> vSdKVPTCZNWbBCT@ge7qjw71mnyeto@lLudoQNVz6IZ8bmRE3CL80lxGpCHx
> bpTIo@x/AsMNLMRtDzvriBL@ErWN1yfdZmDkYzyqeJQ/sNd29fsR0K9CU2gy
> SUPH@HYsbQd/Il/MxTyCHzVFp@k3f9Y8/A1MlXA1i3UswsbmKC48nGvi
> 4qo4fjHAX8nTR0AL2sa2bBPzp2FwttoYQCkpvA16VcRsR3mfPLqiaN5M8W78ZvCHwys
>

Java's behavior stems from the fact that protected offers package-level
visibility. A concept that we don't have in PHP. To offer a counter
example, C# disallows it: https://ideone.com/DkiCeM

PHP started allowing this in 5.2 due to a bug report stating that it should
be possible: https://bugs.php.net/bug.php?id=37212

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

[Pedro Magalhães]

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 the
> current class, classes inheriting from it, and classes from which it
> inherits.


I think that what the note may be referring to is the fact that currently,
a child class can access the protected members of another child class if
this member was declared on the parent class.
However, this is a bug as described on https://bugs.php.net/bug.php?id=50892
which hasn't been fixed yet as the potential BC break makes it more
suitable for a major version.

Regards,
Pedro

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

[Pedro Magalhães]

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 RFC on:
https://wiki.php.net/rfc/negative_array_index

Thank you all for taking part in the discussion and the vote.

Regards,
Pedro

Re: [PHP-DEV] Traits with interfaces

[Pedro Magalhães]

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 producing a
> compile-time error, just as an explicit "implements" declaration would.


To add to that, the receiving class can simply replace the trait method. So
picking up from the same example:
bob();
$b->bib();

Bibble is no longer Bobbable.

Currently, not even an abstract method on a trait enforces anything on the
receiving class. See: https://bugs.php.net/bug.php?id=75449

With that said, I have started some work on "Implicit Interfaces". It
allows a trait to implement an interface in the sense that as long as any
class actually implements a given interface, that class passes the type
check (and instance_of() and ReflectionClass::implementsInterface(),
is_a(), ...). Basically allowing duck typing. It has some similarities to
https://wiki.php.net/rfc/protocol_type_hinting, you can check the current
implementation on
https://github.com/pmmaga/php-src/compare/implicit-interfaces

Regards,
Pedro

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

[Pedro Magalhães]

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:
https://wiki.php.net/rfc/negative_array_index

The vote will be closed on the 16/3.

Regards,
Pedro

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

[Pedro Magalhães]

On Mon, Feb 26, 2018 at 5:25 PM, Pedro Magalhães  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 update on the current status. I'm still trying to solve
a few lasting issues on the PR with the deprecation notice which is why I
the voting hasn't started yet.
I'd prefer to have this all sorted out before the vote starts because if I
can't reach a stable solution for the deprecation notice, I prefer to just
not propose it at all.

Regards,
Pedro

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

[Pedro Magalhães]

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 going
> to be a throwing operation. Apart from the fact that the currently linked
> implementation is not exception-safe (if the deprecation notice throws, the
> element is still inserted), it's quite likely that at least some of the
> >250 uses of zend_hash_next_index_insert will not deal with exceptions
> correctly.
>
> Nikita
>

Hi Nikita, thanks for the feedback.

About the implementation of the deprecation notice, I agree that it should
be updated to be exception-safe.

About the issue if it being dealt with correctly everywhere, I'm honestly
more inclined towards dealing with it when/if it becomes a problem. I think
the number of users that 1) Start an array with a negative number, 2) Use
implicit keys afterwards and 3) Promote Notices to Exceptions must be a
very very small subset. Would you consider this an acceptable approach for
this specific case?

Thanks,
Pedro

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

[Pedro Magalhães]

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.
Including that the example would also emit the deprecation notice.

> NOTE: If accepted, during the deprecation phase the following
> E_DEPRECATED notice would be emitted in cases where the behavior will
> change:
>
> I guess that means also $a[-3] = true; $a[] = false; will emit a
> deprecation notice?
>

Yes, it would.

Thanks,
Pedro

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

[Pedro Magalhães]

On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães  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 which was seen as too big of a BC for a minor
> version. On a second attempt targeting 8.0 I have also canceled the vote as
> the inclusion of a deprecation notice in cases where the behavior will
> change warranted further discussion.
>
> To address these issues, the current version of the RFC will have 2
> separate votes:
> - Introduce the new behavior on 8.0
> - Introduce a deprecation notice on 7.3
>
> For those not familiar with the RFC, the general idea is that currently,
> any array that has a number n as it's first numeric key will have for it's
> next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
> make this consistent by always using n+1 regardless of the sign of n.
> In code:
> $a[-2] = true; // Current: Key is -2, RFC: Key is -2
> $a[] = true; // Current: Key is 0, RFC: Key is -1
> $a[] = true; // Current: Key is 1, RFC: Key is 0
>
> I invite you to read the full RFC: https://wiki.php.net/rfc/
> negative_array_index and bring up any issues you see with the current
> version before the voting period starts.
>
> Looking forward for any feedback.
>
> Regards,
> Pedro Magalhães
>

Hi internals,

I'd like to open the voting for this RFC in 5 days (27/2).
Please bring up any feedback you may have about it before the voting period
starts.

Thanks in advance,
Pedro Magalhães

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

[Pedro Magalhães]

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 which was seen as too big of a BC for a minor
version. On a second attempt targeting 8.0 I have also canceled the vote as
the inclusion of a deprecation notice in cases where the behavior will
change warranted further discussion.

To address these issues, the current version of the RFC will have 2
separate votes:
- Introduce the new behavior on 8.0
- Introduce a deprecation notice on 7.3

For those not familiar with the RFC, the general idea is that currently,
any array that has a number n as it's first numeric key will have for it's
next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
make this consistent by always using n+1 regardless of the sign of n.
In code:
$a[-2] = true; // Current: Key is -2, RFC: Key is -2
$a[] = true; // Current: Key is 0, RFC: Key is -1
$a[] = true; // Current: Key is 1, RFC: Key is 0

I invite you to read the full RFC:
https://wiki.php.net/rfc/negative_array_index and bring up any issues you
see with the current version before the voting period starts.

Looking forward for any feedback.

Regards,
Pedro Magalhães

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

[Pedro Magalhães]

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 are
> > some failed cases. Is there any way I can run a single case and get the
> > result?
> > Further how to debug a php unit case code?
> >
>
> You can use one of
>
> make test TESTS=dir
> sapi/cli/php run-tests.php -P dir
>
> to run tests in a certain directory, or a specific test file.
>
> The first step for debugging would be to look at the .out or .diff file for
> the failing .phpt. There will also be a .php file, which can be used to run
> the test file directly.
>
> Nikita
>

To add to what Nikita said, there will also be a .sh file next to the
failing test that you can use to repeat that test only.

Regards,
Pedro

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

[Pedro Magalhães]

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 a mass-
> edit interface this would also be great, as the CSRF protection makes
> deleting obvious spam requests a bit more annoying than it neeeded. :-D
>
> If you see legit requests drop me (or somebody else with powers) a note
> (including what kind of svn/git karma is needed) and I can set it up.
>
> https://master.php.net/manage/users.php?search=&order=&forward=0&begin=
> 0&max=20&unapproved=1 (I believe this is visible to all @php.net
> account holders)
>
> johannes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
To add to that, AFAIK new requests via http://php.net/git-php.php are not
sending the e-mail they should to this mailing list (PHP Group). Hence the
large number of outstanding requests without follow-up.

Regards,
Pedro

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

[Pedro Magalhães]

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 systems@ mailing list as well (mentioned here:
https://externals.io/message/97214) which may yield some actual response
from the people involved.

Regards,
Pedro

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

[Pedro Magalhães]

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 reflection
> call-site, not the strictness mode used by the file defining the data
> provider.
>

For those that didn't have a look at the PR, my goal was to try to ensure
that if we are looking for which strictness to use, we should look at the
place of the closest "user" call instead of the function (user or internal)
that called the current one. The reason for this problem lies in the fact
that `ZEND_ARG_USES_STRICT_TYPES()` will simply look at the caller
regardless of what it is. Although this is enough to allow calling
functions that were defined as non-strict in a strict manner, it does cause
this kind of shortcomings with callbacks.


> I believe that the proper way to fix this is to handle dynamic function
> invocations differently from direct invocations. Direct invocations should
> use the strictness level of the call-site, while dynamic invocations should
> use the strictness level of the declaration-site.


I agree that this should be about dynamic vs direct instead of user vs
internal but IMHO, making the strictness vary from call-site to
declaration-site depending on that may be a bit too confusing. Would it be
possible/reasonable to try to find the place where the dynamic call was
started? (i.e. the dataProvider, the mapped function for a userland
array_map, etc...)

Regards,
Pedro

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

[Pedro Magalhães]

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 expression in a closure is returned.
http://groovy-lang.org/semantics.html#_optional_return_keyword
http://groovy-lang.org/style-guide.html#_return_keyword_optional

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

[Pedro Magalhães]

>
> > As this is a significant change to the RFC, I'd recommend moving it back
> to
> > discussion first.
>

I have suspended the vote and will be resumed after we discuss the
deprecation notice.


> > Without some further evaluation, I am not sure whether throwing a
> > deprecation from a low level hash API function like this is safe. The
> > deprecation may be converted into an exception and it's not immediately
> > clear that calling code will handle this correctly. In any case, even
> > assuming this is safe, what is the expected behavior if the deprecation
> > notice is converted into an exception? As the implementation stands right
> > now, the element will still be inserted into the array. Is this
> intentional?
> > ("We don't care" is also a valid answer -- it's an edge case.)
>

It seems to be handled correctly. However, the current PR may still change
if there are any issues with it.


> > It would also be nice to quickly check what the performance impact of
> this
> > change is (a micro-benchmark on array appends should be enough). The
> patch
> > adds a number of additional checks in a very hot code-path, which may or
> > may not have a measurable impact.
>

Running the relevant parts of Zend/bench.php on master and the PR branch
indicates that it shouldn't have a serious on performance.


> My concern is that valid code which is working fine and will continue
> working
> fine with the change described in the rfc will now start spitting out
> notices.
>
> How often and how many? I don't know.
>

That's a very valid concern. I believe that the benefit outweighs the
potential noise but, if most people disagree, there are other options like
waiting until the last 7.x or not introducing it at all.

In this case I would like to hear some more feedback on the usefulness of
the deprecation notice. If necessary, I can open a second vote for the
deprecation notice keeping the first one only about the main point of the
RFC.

Regards,
Pedro

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

[Pedro Magalhães]

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 such cases.

I have closed the current vote (YES 14 - 16 NO) and opened a new one for
the revised RFC targeting the next major version.

You can vote (again) at https://wiki.php.net/rfc/negative_array_index
until 28/6/2017 19:00 UTC.

Regards,
Pedro

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

[Pedro Magalhães]

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 project. It
> would be great, IMO, to open a 'Approved for 8.0' section on the RFC page
> now, and your RFC could proudly be the 1st one to enter it.
>

I agree with your suggestion and general sentiment so I propose to do the
following:

   - The current voting widget refers to introducing the change on 7.2.
   (Will be mentioned on the RFC page)
   - Add a new voting widget for introducing the change on 8.0.
   - Extend the voting period for one more week than originally planned
   until 27/6/2017 18:00 UTC.

Additionally, since some people also mentioned the difficulty in detecting
this change, if the vote for 8.0 passes, I suggest to introduce a
E_DEPRECATED notice where the implicit keys will change. You can see that
implementation here:
https://github.com/php/php-src/compare/master...pmmaga:negative-array-deprecated
Would it make sense to include an extra voting widget for the introduction
of the notice?

Given that we are on the voting phase I would oppose changing anything by
principle, but given that most of the discussion on the topic only started
when the vote was started and what is dividing the vote is the timing, I
think it makes sense to update the RFC in this case. Let me know what you
think.

Thanks,
Pedro

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

[Pedro Magalhães]

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 you or your
> work, as I'd also like to change such inconsistent behavior, but the
> probability of BC break is too high, IMO.
>

I will not change the target version now during the voting phase. Also
because it wouldn't make sense to vote for a feature for 8.0 yet. If the
RFC is rejected and the sentiment is that most people would agree with the
change but not with the timing, I will propose it again when RFCs for 8.0
are relevant.

Thanks,
Pedro

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

[Pedro Magalhães]

On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins 
wrote:

> On 7 June 2017 15:23:13 BST, "Pedro Magalhães"  wrote:
> >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
>
>
> I'm sorry, I don't follow. What rule is broken, incidentally or
> explicitly, by that RFC?
>
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

The page that was already mentioned on this thread:
https://wiki.php.net/rfc/releaseprocess#releases_cycle explicitly states
the following:

x.y.z to x.y+1.z
> Backward compatibility must be kept


However, a number of already implemented RFCs for 7.2 do not follow that
rule strictly:

   - https://wiki.php.net/rfc/number_format_negative_zero
   - https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts
   - https://wiki.php.net/rfc/deprecate-bareword-strings
   - https://wiki.php.net/rfc/get_class_disallow_null_parameter
   - https://wiki.php.net/rfc/counting_non_countables
   - https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp
   - https://wiki.php.net/rfc/hash-context.as-resource
   - https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
   - As well as some of the RFCs still pending implementation

I don't mean at all that these should not have been accepted. Especially
the ones that initiate a deprecation phase. But it is seems to me that this
RFC does not break any rule that has been upheld strictly up to this point.

Regards,
Pedro

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

[Pedro Magalhães]

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

[Pedro Magalhães]

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 20/6/2017 18:00 UTC.

Thanks,
Pedro

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

[Pedro Magalhães]

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 previous discussion: https://externals.io/thread/712
And the PR (also some discussion): https://github.com/php/php-src/pull/2383

Voting is open from now until 20/6/2017 18:00 UTC.

Regards,
Pedro

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

[Pedro Magalhães]

On Tue, Jun 6, 2017 at 7:22 PM, Sara Golemon  wrote:

> On Tue, Jun 6, 2017 at 7:06 AM, Pedro Magalhães  wrote:
> > Given that I got no more feedback on this, I'm ready to move it to
> voting.
> > However, before doing so, I would like to hear some feedback from 7.2 RMs
> > about the timing. I think the impact in real applications would be pretty
> > low but there is still the possibility of a subtle BC.
> >
> > Sara & Remi, would you prefer I wait for the next major for this or would
> > you be ok with 7.2?
> >
> I can't see why not. Go for it. Make sure you include a NEWS entry
> when (if) you merge it. :D
>
> -Sara
>

Thanks for the feedback. Will do :)
Voting announcement will follow shortly.

Regards,
Pedro

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

[Pedro Magalhães]

On Sun, May 21, 2017 at 5:29 PM, Pedro Magalhães  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 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 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.
>
> Regards,
> Pedro Magalhães
>

Hi all,

Given that I got no more feedback on this, I'm ready to move it to voting.
However, before doing so, I would like to hear some feedback from 7.2 RMs
about the timing. I think the impact in real applications would be pretty
low but there is still the possibility of a subtle BC.

Sara & Remi, would you prefer I wait for the next major for this or would
you be ok with 7.2?

Thanks in advance.

Regards,
Pedro

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

[Pedro Magalhães]

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 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 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.

Regards,
Pedro Magalhães

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

[Pedro Magalhães]

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]


The first example behaves how you would expect with this patch (third
element gets -4).
In the second example however, it would act the "old" way. Thanks for the
hint! I'm working on making it consistent in that case as well.

Would you be willing to draft an RFC for this change? If you're not
> familiar with the process, have a look at this:
> https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process


Yes, I'm already familiar with it. It clearly seems to be the way forward
so I'll create a draft once I'm done with the implementation fixes/further
discussion.


> - Exactly what behaviour will change, and how? We already have three
> different things that are affected, and there may well be others.
>

If the first numeric index - n - of an array is negative (however that
array is created), the next element (however it is inserted) will not
default to 0, but will have the index n + 1.


> - What code might rely on the current behaviour? What kind of bugs might
> such code exhibit if it's not updated after the change? How can users write
> code that will work the same before and after the change?
>

I have a hard time coming up with a use case for it but basically, any code
relying on the defaulting to 0. Basically, the only safe way I see is that
if you don't set explicit keys, you probably shouldn't try to access array
elements by an explicit key.


> - On the other side, what are the benefits of the change? What is the harm
> caused by the current behaviour, e.g. potential for bugs or mistakes?
>

IMHO, the benefit is that you naturally expect a subsequent element to get
the n+1 key regardless of n being positive or negative. The current
implementation gives you an effect that you only discover once you hit it
or read the manual page about array_fill or the note you mentioned before
on the page about arrays.

Regards,
Pedro

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

[Pedro Magalhães]

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 would indeed. Internally, nNextFreeElement is initialized with 0 and
updates on larger values. In the PR (
https://github.com/php/php-src/pull/2383/files#diff-fd78a0a3f78ea28c6907f907f25b908eR798
) I'm allowing it to be set to a negative value if it is the first element.


> Currently, this is completely consistent: https://3v4l.org/hXAsf Indeed,
> I would say this is the missing explanation of why array_fill works the way
> it does.


With this PR all of your examples would behave consistently but with the
negative indexes.


> As mentioned above, if no key is specified, the maximum of  the existing
>> integer indices is taken, and the new key will be that
>>
> maximum value plus 1 (but at least 0). If no integer indices exist yet,
> the key will be 0 (zero).
>

The "but at least 0" is exactly what this PR would change.


> The point right now is that array_fill's behaviour is actually consistent
> with the rest of the language, and while the value of that behaviour is
> questionable, changing it now would be a major decision.


I completely agree on the impact of this change. But I also believe that
this behaviour would be preferable.

Thank you for the feedback.

Regards,
Pedro

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

[Pedro Magalhães]

On Wed, Feb 15, 2017 at 7:28 PM, Pedro Magalhães  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 goal is to make the result of array_fill more in line with what
> you would expect if the start_index is a negative 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
>

Bump on this topic as I would like to hear some feedback.

As a clarification, the current implementation of the PR affects arrays in
general, not only array_fill. Any array that starts with a negative index
would continue from that index instead of 0. Meaning that [-2 => true,
true, true] would now return [-2 => true, -1 => true, 0 => true] instead of
[-2 => true, 0 => true, 1 => true].

Regards,
Pedro

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

[Pedro Magalhães]

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

[Pedro Magalhães]

>
>
> 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

[Pedro Magalhães]

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 goal is to make the result of array_fill more in line with what
you would expect if the start_index is a negative 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

[Pedro Magalhães]

On Wed, Feb 15, 2017 at 2:11 PM, Christoph M. Becker 
wrote:

> On 15.02.2017 at 13:52, Zeev Suraski wrote:
>
> >> -Original Message-
> >> From: Dan Ackroyd [mailto:dan...@basereality.com]
> >> Sent: Tuesday, February 14, 2017 8:22 PM
> >> To: Pedro Magalhães 
> >> Cc: internals@lists.php.net
> >> Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation
> >>
> >> I thought this RFC was likely to pass easily.
> >>
> >> It's always slightly unfortunate when RFCs are either accepted or
> rejected by
> >> a small margin, particularly when there doesn't seem to have been any
> >> voices against it.
> >>
> >> Please could anyone who voted no, illuminate the rest of us as to why
> voting
> >> no was the correct option?
> >
> > I can't speak for others, but for me, it's simply because there's no
> reason to do it (remove it), while there may/might be a reason to keep it
> going forward.  Keeping it comes at zero cost, and if we ever do need a
> binary string notation, it sounds more than likely that we'll pick this
> one.  I see no value at removing it even if there's a small chance we'll
> need it again.
>
> For similar reasoning, I abstained from voting.  Actually, I'm -0.1 on
> the deprecation.
>
> --
> Christoph M. Becker
>
>
Hi all,

Thanks for contributing to the discussion.

One week ago marked 10 years since the forward compatibility was
introduced(5.2.1). This deprecation would allow us to remove them in the
future if no implementation ever comes forward. If that implementation ever
comes, we could still revert this. I think it's important to mention that
this is not a removal, it's only the first step in that direction.

I understand the reasoning that "it doesn't hurt". However, I would argue
that for someone new to the language, this can potentially be confusing. On
the type juggling page, the forward compatibility is mentioned but - AFAIK
- nowhere else (also not on the page about the String type). Users are left
on their one to figure it out. Searching for "php binary string" leads only
to the pack/unpack pages and questions from confused users on StackOverflow.

Given how long ago this was introduced, and how it still produces no
effect, it seemed like a good time to start preparing for it's removal.

Best regards,
Pedro

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

[Pedro Magalhães]

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  wrote:

> On Fri, Feb 3, 2017 at 1:53 PM, Pedro Magalhães  wrote:
>
> > 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
> >
>
> I'm +1 on this, conditional on the deprecation not being thrown if
> token_get_all() is used. The RFC currently doesn't say whether this is the
> case.
>
> Nikita
>

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

[Pedro Magalhães]

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

[Pedro Magalhães]

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

[Pedro Magalhães]

Hi all.

After the previous discussion about the removal of the binary string prefix
and cast,
I have prepared an RFC to implement a deprecation phase for those.

You can find the RFC here:
https://wiki.php.net/rfc/binary_string_deprecation

Looking forward to hear your feedback on the RFC or the implementation
patches.

Best regards,
Pedro Magalhães

[PHP-DEV] Wiki RFC karma request: pmmaga

[Pedro Magalhães]

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
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Pedro Magalhães]

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 introduced
for forward compatibility with the PHP6 project. As it is known, that
project never came to be. However, these are still accepted by the
language scanner although ignored from then on.

This PR aims at removing those as they are naturally confusing given
that they are simply ignored or, in the case of the cast, the same as
casting to string.

However, I've separated this PR in 2 commits because the removal of
the (binary) cast will bring a more serious BC break issue: On the
PHAR extension, the current default stub for PHAR's makes use of the
binary cast. I've removed it from the default stub and fixed the tests
that made use of it but this means that the old PHARs that make use of
this default stub will be broken.

What seemed to be a simple task actually turned out to be far more
complex given the number of tests that were written with this forward
compatibility in mind.

I would be happy to transform this into an RFC if you think it would
be appropriate.


Any feedback would be greatly appreciated.

Best regards,
Pedro Magalhães


Hello, internals!

Based on the feedback here and on GitHub, this change should go through
a deprecation phase and there should be an RFC about it.

This deprecation is also covered on Nikita's deprecations RFC but we
agreed to take this on separately as it has the BC break issue for old
PHAR's.

Given that, I would like to request for rfc karma on the wiki for my
user: "pmmaga"

Thank you in advance,
Pedro Magalhães



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Binary string forward compatibility removal

[Pedro Magalhães]

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 introduced for 
forward compatibility with the PHP6 project. As it is known, that 
project never came to be. However, these are still accepted by the 
language scanner although ignored from then on.


This PR aims at removing those as they are naturally confusing given 
that they are simply ignored or, in the case of the cast, the same as 
casting to string.


However, I've separated this PR in 2 commits because the removal of the 
(binary) cast will bring a more serious BC break issue: On the PHAR 
extension, the current default stub for PHAR's makes use of the binary 
cast. I've removed it from the default stub and fixed the tests that 
made use of it but this means that the old PHARs that make use of this 
default stub will be broken.


What seemed to be a simple task actually turned out to be far more 
complex given the number of tests that were written with this forward 
compatibility in mind.


I would be happy to transform 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