Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Peter Cowburn]

On Mon, 4 Jul 2022 at 11:11, Jakub Zelenka  wrote:

> On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot 
> wrote:
>
> > Hi internals,
> >
> > If the rest also thinks the RFC is good to go, I suggest we start a vote
> > coming week.
> > As this is my first RFC, I'm not so sure how this typically gets kicked
> > off, so I'd like to know what I need to do!
> >
>
> You just need to change status in RFC to Voting and in voting section set
> the date range and add doodle poll - you can basically copy it from one of
> the open RFC's (see for example code in
> https://wiki.php.net/rfc/fetch_property_in_const_expressions ). Then you
> just need to send email to internals with subject prefixed with [RFC][VOTE]
> or similar. As noted you need to do it today or latest tomorrow. Feel free
> to let me know if you are too busy or something is not clear.
>
> I would recommend not to do any last time changes as in such case you
> should probably give an extra time for dicusion which means it won't make
> the feature freeze and will have to wait for another year. In my opinion it
> is good as it is. The tabs can be later added as an extra flag. If the flag
> is set, we could just change default value for indent to 1 and use tabs but
> it would be still possible for users to set indent size if they wish. I
> think that's something that makes most sense to me and doesn't impact the
> current RFC in any way.
>
> Regards
>
> Jakub
>

My thoughts might be firmly in the realms of "too little, too late" since
the vote is open already, so by all means choose to ignore.

Things that I would have liked to have seen in the RFC document:
* the mention/consideration of a user-specified indent string
  (even if under a "Rejected Features" section with some details about the
rejection)
* details on the new parameter's interaction with / dependency on
JSON_PRETTY_PRINT.
* related, details on what happens when the new parameter is used without
JSON_PRETTY_PRINT.
  (I'd personally like to have JSON_PRETTY_PRINT be implicitly added if the
new parameter is used, or it could
   raise an error, or it could be ignored as seems to be the case but isn't
explicltly mentioned)
* details on allowed values of the new parameter, e.g. what happens with
negative, or stupidly huge, values?
* some summary (more than none!) of discussion topics / design decisions
resulting from the mailing list thread(s)

The RFC currently states (the quote is two-thirds of the proposal text,
minus examples):

> By default, an indentation of 4 spaces will be applied, just like the
original json_encode behaviour with the JSON_PRETTY_PRINT option.
>
> When the indent parameter is passed a different value, an indentation of
N spaces will be applied.

Even after several readings of the proposal, I thought that you were
proposing that json_encode() always be pretty-printed and indented.

Even the examples weren't particularly helpful in correcting
that mis-reading. It took me far too long to understand (hopefully
correctly) that:
* "By default..." means "When the flags include JSON_PRETTY_PRINT and the
indent parameter is not passed (or 4 is passed)...".
* "When the indent parameter is passed..." really means "When the flags
include JSON_PRETTY_PRINT and the indent parameter is passed...".
* Any calls to json_encode() without JSON_PRETTY_PRINT, with or without the
indent parameter, behave identically to now.

The "Unaffected PHP Functionality" section only muddied the waters further:
"Normal usage ... of the json_encode function will not be affected, as
the default of 4 spaces will still be in effect."

My point being, I don't think this document was anywhere near ready... but
feel free to disagree.

Just to finish up, wouldn't it be nice to have the following?..

json_encode($value, indent: 2)

Regards,

Peter

Re: [PHP-DEV] Revisiting Userland Operator Overloads

[Peter Cowburn]

On Mon, 9 Aug 2021 at 18:48, Jordan LeDoux  wrote:

>
> You claim that this would be documented on php.net and this would be
> sufficient. Yet the DateTime class has had operator overloads for
> comparison operators since 5.2 and there is still *zero* mention on
> php.net
> (that I am aware of or can find) of this. Not even a mention that it
> exists, let alone what the override behavior is. *Not even in the god-awful
> comments on the manual.*
>

For future reference: https://www.php.net/manual/en/datetime.diff.php

Re: [PHP-DEV] [VOTE] Add PDO function: mysqlGetWarningCount

[Peter Cowburn]

>
> On Jul 6, 2021, at 08:34, Daniel Beardsley  wrote:



Voting will be open till 2020-07-21
>

This date has passed, yet the vote is still ongoing.
Daniel, could you please close the vote and do the usual follow up tasks?
If Daniel is unavailable, what is the process for *someone else* doing
those things?

Re: [PHP-DEV] Vote!

[Peter Cowburn]

Hi Daniel,

Please create a new email thread, with the tag [VOTE] in the subject along
with the
name of your RFC:  "[VOTE] Add PDO function: mysqlGetWarningCount"

Threads with ambiguous titles like this one (subject is just "Vote!") are
likely to
be overlooked / ignored.

It would also have been courteous to send a reminder of the RFC before
opening
the vote (e.g. "I'm going to start voting next week, any more feedback
before then is welcome.").
This topic was last discussed, from what I can see, at the beginning of
April (2021) so
a vote happening now (July 2021) is pretty unexpected.

Kind regards,

Peter

On Tue, 6 Jul 2021 at 10:47, Daniel Beardsley  wrote:

> I've moved my RFC to the voting phase.
>
> Voting will be open till 2020-07-21
>
> https://wiki.php.net/rfc/pdo-mysql-get-warning-count
>
> The pull request (with tests) is here:
> https://github.com/php/php-src/pull/6677
>
> Thanks for your time!
> Daniel
>

Re: [PHP-DEV] Re: edit.php.net is down

[Peter Cowburn]

On Thu, 30 Jul 2020 at 13:30, Сергей Пантелеев 
wrote:

> Thanks, Peter!
>
> PR was merged.
>
> Now, should we use https://edit-new.php.net/ or edit php.net zone like
> that (
> https://github.com/saundefined/systems/commit/955c6145933b59a67237c5257766aa1ff5ee225c
> )?
>

Neither, not until the edit-new box is up and running smoothly.  Volunteers
to make that happen are welcome.


>
> —
> wbr
> Sergey Panteleev
> On 30 Jul 2020, 11:44 +0300, Сергей Пантелеев ,
> wrote:
>
> Hi,
>
> Was created a new edit box (http://edit-new.php.net/,
> https://github.com/php/systems/commit/c79853fe86f9e844a39bd36b7918298a4b924c5d),
> but login throws an error.
>
> It fixed easy, but I have no karma to merge this fix (
> https://github.com/php/web-doc-editor/pull/18)
>
> As a temporary solution you can use it: http://194.67.87.221/
>
> But it would be great if the official editor was restored
>
> —
> wbr
> Sergey Panteleev
> On 30 Jul 2020, 11:34 +0300, Andreas Heigl , wrote:
>
> Hey folks.
>
> Edit.php.net is down. And from the tweet I got not only for some hours
> (https://twitter.com/arueckauer/status/1288728325331079168)
>
> Can either anyone with access to the system (pb11.php.net) have a look
> or grant me access so that I can have a look? According to
> https://wiki.php.net/systems/pb11 the following people have access:
> Alexander (irker), Hannes, Michael, Martin, Philip, Rasmus, Yannick
>
> Even though I know that edit.php.net will become obsolete once we manage
> to get the conversion from SVN to git up and running (I'm currently
> struggling with http://doc.php.net/revcheck.php) it currently is the
> official way to contribute to the docs. So it should be up and running IMO.
>
> Thanks for a short response!
>
> Cheers
>
> Andreas
>
>
> --
> ,,,
> (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl |
> | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
> | http://andreas.heigl.org http://hei.gl/wiFKy7 |
> +-+
> | http://hei.gl/root-ca |
> +-+
>
>

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

[Peter Cowburn]

(Top posting because... sue me.)

I hereby propose to use @[] syntax for attributes.

No need to vote; it's clearly the best, nay only, real option.

Make it so.

P.S. Sorry for suggesting @@ earlier, I've no idea what I was thinking.
Creating new syntax is HARD!
P.P.S. <3

On Tue, 28 Jul 2020 at 20:59, Marcio Almada  wrote:

> Hi,
>
> >
> > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown 
> > wrote:
> >
> > >
> > > Hi Joe,
> > >
> > > From the perspective of looks alone I don't care much one way or the
> > > other between @@ and #[]. However, I don't find the arguments for #[]
> > > in this RFC very compelling, and it ignores some of the other downsides
> > > of #[] compared to @@ that should be highlighted. Let's go through the
> > > arguments from the RFC:
> > >
> >
> > 
> >
> > Theodore, thanks for your comments, time, and work on the Shorter
> Attribute
> > Syntax RFC. I appreciate your feedback and I'm also of the mind where I
> > don't care based on looks alone. The RFC also notes the @@ issues have
> been
> > resolved by the RFC closing at the end of the month.
> >
> > My motivation for this RFC is based on 2 things:
> >
> > Firstly, the @@ syntax makes parsing harder (although not impossible) on
> > CLI tools such as PHPCS. Therefore IMHO internals should make the best
> > effort to avoid this when possible.
> >
> > Secondly, I'd like to see internals use this as a point in the future to
> > avoid this kind of issue where we need to vote on something yet again
> > instead of taking the runner up in a ranked-choice vote. Originally this
> > was my main motivation until I saw the issues raised by the PHPCS users.
> >
>
> Is this issue documented somewhere on github or on any other platform?
> I'd like to see the discussion and maybe participate in it.
>
> Thanks,
> Márcio
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open

[Peter Cowburn]

On Mon, 20 Apr 2020 at 22:36, Marco Pivetta  wrote:

> Hey Andrea,
>
> On Mon, Apr 20, 2020, 23:25 Andrea Faulds  wrote:
>
> > Hi,
> >
> > Benjamin Eberlei wrote:
> > > Hello,
> > >
> > > I have opened the vote on the Attributes v2 RFC. The voting will be
> open
> > > until two weeks from now, May 4th 2020, noon UTC.
> > >
> > > RFC: https://wiki.php.net/rfc/attributes_v2


I know that I'm "too late" to be making suggestions, but I would like to see
a new "@@" operator over the proposed <<...>> or @:.

While it is possible (!!) that some code is already using a double
@-operator
in a way that would conflict, I'd posit that it is a reasonable BC break in
return
for a subjectively nicer (for want of a better word) attribute operator.

Nikita and Sara shared similar grumblings in unofficial channels [1] [2].

However, there is something to be said for just deciding on *anything* and
rolling forward with it.

[1] https://chat.stackoverflow.com/rooms/11/conversation/at-at-01
and https://chat.stackoverflow.com/rooms/11/conversation/at-at-02
[2]
https://www.reddit.com/r/PHP/comments/g4psl5/rfc_attributes_vote_is_open_now/fnz97fk/


>
> > >
> > > Thank you everyone for taking part in the detailed discussion.
> > >
> > > greetings
> > > Benjamin
> > >
> >
> > Thanks for putting this to a vote. I remember I had some comments about
> > autoloading behaviour and you changed the behaviour in the RFC, but I
> > didn't get around to reading it again. I am concerned though that it
> > doesn't seem to say anymore when autoloading happens, if at all? Can
> > that be clarified?
> >
> > Thanks,
> > Andrea
> >
>
> From my review of the tests, autoloading occurs when an object is being
> requested (via `newInstance()` call on a reflection attribute).
>
> Until then, the same semantics as the `::class` pseudo-constant apply.
>
> >
>

Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas

[Peter Cowburn]

On Wed, 15 Jan 2020 at 09:33, Nicolas Grekas 
wrote:

> Le mer. 15 janv. 2020 à 08:36, Pierre Joye  a écrit
> :
>
> > Good afternoon,
> >
> > What a bold rejection, a bit surprising.
> >
> > For one, there is a consensus on key community having a vote right since
> we
> > introduced rfc. We have been more strict but the consensus remains.
> >
> > Secondly, yes, being an active contributor makes it amazingly easier to
> > actually have a vote, de facto.
> >
> > Which brings me to why we rejected Nicolas request. Nicolas has
> > contributed, and is contributing. Countless on spot bugs reports, working
> > on rfc, and working these days on actually providing patches for new
> > features.
> >
> > So I kindly ask to accept his request and if anyone has issues about non
> > (lot of)code contributors being to vote, then bring it on via a rfc and
> let
> > us take a decision from there. But blocking Nicolas is not a good move as
> > of now
> >
> > best,
> >
> > On Tue, Jan 14, 2020, 7:20 PM PHP Group  wrote:
> >
> > > VCS Account Rejected: nicolasgrekas rejected by salathe /o\
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
>
> Thank you Pierre.
>
> I very much look forward to the rejection being reconsidered.
>

Firstly, I apologise for the rash decision and rejection, and any offence
caused to you as a result.
I made a mistake and it won't happen again. I will no longer handle any
account requests outside
of the docs team. Please re-submit the VCS account request and we can all
move forward from there.


>
> Note that contrary to what is suggested in another subthread, I'm not
> seeking for a community representative mandate nor justifying my request by
> my supposed "status" in userland PHP. I did not mention Symfony in my
> application because this has nothing to do with it, please don't make it a
> "Symfony wants a seat" discussion. Yes, I'm making it personal, because it
> is: I'm asking on my own personal behalf, as a free and independent soul
> and mind.
>
> My involvement in PHP itself pre-dates anything else I've done in the OSS
> space by more than 10 years, here are my first bug reports, back in 2002,
> PHP 4.1
> <
> https://bugs.php.net/search.php?search_for==0=30_by==DESC=display=All_type=All=All_os==_id==_email=okin7+at+yahoo+dot+fr_age=0_updated=0_by=
> >.
> Since then I've reported apparently 60 bug reports
> <
> https://bugs.php.net/search.php?cmd=display_email=nicolas.grekas%2Bphp%40gmail.com_by=ts2=DESC=30=All_by=ts2
> >
> and contributed to many others
> <
> https://bugs.php.net/search.php?search_for==0=30_by==DESC=display=All_type=All=All_os==_id==_email=_age=0_updated=0_by=nicolas.grekas%2Bphp%40gmail.com
> >
> .
>
> Of course, I'm also involved in userland PHP and I think that's an integral
> part of my application. I can give you some track records on the topic if
> you want, everything is public.
>
> If participating in discussions on php-internals counts, I apparently
> contributed 177 times here
> , the first
> message in 2010.
>
> Since contributing to the source code is also nice to accredit my request,
> I
> do own some commits in the git history
> . That's a
> ridiculously low number of them I agree. Many will consider life itself as
> ridiculous, so I'm still proud of them, very modestly.
>
> And of course, I've got this pending PR/to-be-RFC
>  showing I'm not going to stop
> here.
>
> But if that's not enough, what's the bar? Who else passed this scrutiny?
>
> Thanks,
> Nicolas
>

Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas

[Peter Cowburn]

On Tue, 14 Jan 2020 at 12:27, Nicolas Grekas 
wrote:

> Le mar. 14 janv. 2020 à 13:20, PHP Group  a écrit :
>
> > VCS Account Rejected: nicolasgrekas rejected by salathe /o\
> >
>
> So, what's the process to get a vote now?
> Do I need sponsor? Something else?
>

Hi,

While the notion of community representative votes was documented at the
time of the RFC process introduction, it is not something that is supported
by the project.
Please become an active contributor to this project: in particular active
enough to get yourself a PHP.net VCS account. One of the (many!) benefits
of doing so is being granted RFC voting privileges.

Regards,
Peter

Re: [PHP-DEV] Re: Changelog / upgrading notes for promoted warnings

[Peter Cowburn]

On Fri, 20 Dec 2019 at 09:31, Rowan Tommins  wrote:

> On Fri, 20 Dec 2019 at 08:37, Christoph M. Becker 
> wrote:
>
> > Maybe a sensible compromise would be to assemble a detailed list of
> > these changes, and to hand it over to the doc team at some point, so
> > that the manual pages could (hopefully) be updated in time just before
> > PHP 8.0.0 will be released.  Then users could check the manual's
> > changelog[1] regarding the details.
> >
>
>
> Yes, that sounds reasonable. In many cases, the individual function listing
> should also have a note added at the same time; and at some future date,
> some will be able to lose their "may return false" notes.


This is usually where the UPGRADING document comes in to play. While
watching all of the PRs against master I've very much not been looking
forward
to making sense of all of changes when it comes to updating the PHP manual
to
reflect them.


>
>
> On Fri, 20 Dec 2019 at 00:34, G. P. B.  wrote:
> > Moreover, I'm not sure it's helpful to have a massive list of functions
> where some warnings have been promoted and others not. But this is only my
> opinion
>
> I think this makes it even *more* important to collect the list of changes.
> In the case of password_hash, my understanding is that it will now never
> return false; in other cases, it may still be necessary to check the return
> value. The documentation should clearly state which is the case for each
> function, so we need to keep track of which functions are fully-promoted
> and which partially-promoted.
>

> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

[Peter Cowburn]

On Thu, 26 Sep 2019 at 08:42, Nikita Popov  wrote:

> On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
> >
> > There are 4 votes, all of them independent. The first 3 are for specific
> > cases that were controversial during the discussion, the last one is for
> > the remainder of the proposal.
> >
> > Voting closes 2019-09-26.
> >
>
> Voting has closed with the final outcome being:
>
>  * Undefined variables: 36 exception, 18 warning, 10 notice. Exception
> declined with 56% in favor. Warning accepted with 84% combined majority.
>

I just want to go on the record in saying that I am very, very disappointed
that a choice that only got 28% of the overall votes, and only 33% of votes
in the "we want change" scenario, is being taken as the will of the
overwhelming majority, which is the bar that is needed to be crossed for
RFC votes. This is wholly irresponsible.


>  * Undefined array index: 42 warning, 21 notice. Warning accepted with 2/3
> majority.
>  * Division by zero: 52 exception, 8 warning. Exception accepted with 87%
> majority.
>  * Remainder: 54 yes, 3 no. Accepted with 95% majority.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Offtopic discussions

[Peter Cowburn]

On Fri, 13 Sep 2019 at 09:30, Brent  wrote:

> Hello all
>
> I've noticed a trend in many threads here on the internals list where an
> RFC is being discussed, but one way or another we always end up with the
> same offtopic conversation about how PHP should evolve. While I think this
> is a good conversation to have, I don't think it's beneficial for the RFC
> process to have the same discussion happening over and over again,
> effectively having the RFC discussion hijacked by another one. I can only
> imagine it must be quite difficult for the people working on these RFCs to
> filter out ontopic from offtopic content.
>
> Here are a few examples:
>
> - Reclassifying engine warnings (https://externals.io/message/106713)
> - Short open tags (https://externals.io/message/106384)
> - Namespaced scope declares (https://externals.io/message/101323)
> - Call-site send by ref (https://externals.io/message/101254)
> - PHP 7.4 deprecations (https://externals.io/message/106012)
>
> Maybe someone has a good suggestion on how people can voice their opinion
> on the future of PHP, without polluting several RFC discussions.
>

Start a new thread (or threads) instead of replying to RFC threads. 樂


> Kinds regards
> Brent
>

Re: [PHP-DEV] Counterargument to Short Tags Deprecation (was: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2)

[Peter Cowburn]

On Mon, 5 Aug 2019 at 23:51, Zeev Suraski  wrote:

> On Mon, Aug 5, 2019 at 10:05 PM G. P. B.  wrote:
>
> >
> > I'd prefer Dan's approach and having a seperate page linked at the top of
> > the RFC.
> >
> > I'll start voting tomorrow and will link to your page in the same message
> > as the voting announcement.
> >
>
> Thanks George.  I created a page with a counterargument to the deprecation
> proposal here:
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags and
> linked it from the RFC.
>
> If others have additional input to add there, please let me know.
>

Please keep this sort of content inside the relevant mailing list thread,
we don't need yet more places to go hunting for comments on RFCs.  I'm not
sure what the value is of a dedicated wiki page is (for context, I have
read Dan's thread suggesting the idea), other than to have a new soap box
to shout from for the most loud voices.  Key feedback to RFCs should at
minimum appear in the respective discussion thread on the list.  If it
does, then this page is redundant.  If it doesn't, then it should.


>
> Zeev
>

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

[Peter Cowburn]

On Wed, 24 Jul 2019 at 13:21, Nikita Popov  wrote:

> On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn 
> wrote:
>
>>
>>
>> On Tue, 23 Jul 2019 at 22:03, Nikita Popov  wrote:
>>
>>> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins 
>>> wrote:
>>>
>>> > On 23 July 2019 18:54:48 BST, "G. P. B." 
>>> wrote:
>>> > >The only point of contention of this RFC that I potentially see is the
>>> > >removal in PHP 8.1 after short open tags being a Parse Error in PHP
>>> 8.0
>>> > >instead of it being removed in PHP 9 after it having had a whole major
>>> > >version release cycle.
>>> >
>>> > Given that you've already predicted that this will be controversial,
>>> could
>>> > you provide some rationale for it? Unless there's a major burden in
>>> > maintaining the parser error behaviour for a few years, waiting for the
>>> > next major version would seem both safer and more in line with official
>>> > versioning policy.
>>> >
>>> > As with deprecation itself, any violation of the "no breaking changes"
>>> > rule, however slight, should have an explicit justification. If I had a
>>> > vote, any RFC omitting such a justification would receive an automatic
>>> "no"
>>> > from me.
>>> >
>>>
>>> I agree. I don't think there's a pressing need to do the "full removal"
>>> in
>>> PHP 8.1 in particular, so it makes more sense to this in the next major
>>> version (9.0), as usual.
>>>
>>> Nikita
>>>
>>
>> Would you (George, Nikita) consider removing the details about the
>> eventual removal of the feature from this RFC?  We can run with the error
>> for a bunch of releases / years, and see what happens.  I don't see why we
>> should necessarily decide now on something that might be 5 years or more
>> away.
>>
>
> I don't see a benefit in leaving this open-ended and prefer to have a
> fixed timeline for this. The full removal in 9.0 is already very, very
> conservative. Using short tags will have produced a fatal error for a whole
> major version at that point. If necessary the question can be reevaluated
> at that time, but the burden of proof must be on the people arguing an
> additional delay, not the other way around.
>

Hypothetically, it can be re-evaluated sooner, particularly if "everyone"
in the PHP ecosystem appears to respond very well once the deprecation and
error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be
a point being made if/when that discussion comes along.  My point is that
the removal release/date, in my opinion, is a detail that we don't need to
be concerned with right now and it's just adding noise.  You disagree, and
that's totally okay.


>
> Nikita
>

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

[Peter Cowburn]

On Tue, 23 Jul 2019 at 22:03, Nikita Popov  wrote:

> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins 
> wrote:
>
> > On 23 July 2019 18:54:48 BST, "G. P. B." 
> wrote:
> > >The only point of contention of this RFC that I potentially see is the
> > >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
> > >instead of it being removed in PHP 9 after it having had a whole major
> > >version release cycle.
> >
> > Given that you've already predicted that this will be controversial,
> could
> > you provide some rationale for it? Unless there's a major burden in
> > maintaining the parser error behaviour for a few years, waiting for the
> > next major version would seem both safer and more in line with official
> > versioning policy.
> >
> > As with deprecation itself, any violation of the "no breaking changes"
> > rule, however slight, should have an explicit justification. If I had a
> > vote, any RFC omitting such a justification would receive an automatic
> "no"
> > from me.
> >
>
> I agree. I don't think there's a pressing need to do the "full removal" in
> PHP 8.1 in particular, so it makes more sense to this in the next major
> version (9.0), as usual.
>
> Nikita
>

Would you (George, Nikita) consider removing the details about the eventual
removal of the feature from this RFC?  We can run with the error for a
bunch of releases / years, and see what happens.  I don't see why we should
necessarily decide now on something that might be 5 years or more away.

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Peter Cowburn]

On Thu, 18 Jul 2019 at 12:10, Christoph M. Becker  wrote:

> On 18.07.2019 at 01:14, Stanislav Malyshev wrote:
>
> >> the quick fix descriptions of bugs.php.net[1] need some update.  To my
> >> knowledge, these come from the database, so could anybody with access to
> >> it please take a look?
> >
> > Ideally, I think this should be in PHP file and not database, so it will
> > be modifyable by project members without needing shell access & DB
> password.
>
> I agree that this would be the best solution in the long run, and it
> shouldn't be hard to adapt ReasonRepository[1] to read from a file
> instead of the DB.
>
> Any volunteers?
>

I'm not sure if anyone other than us is still using this source code
(looking at the MySQL guys).  If not, can we just include the reasons in
the source directly, and forget about the database or a special file
containing the reasons?


>
> [1]
> <
> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
> >
>
> Thanks,
> Christoph
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Peter Cowburn]

On Fri, 5 Jul 2019 at 05:17, Theodore Brown  wrote:

> On Thu, July 4, 2019 at 9:13 PM Will  wrote:
>
> > After 15 days of discussion I have opened up voting on the following RFC
> > (https://wiki.php.net/rfc/add_str_begin_and_end_functions) .
> >
> > You can access the voting page here:
> > https://wiki.php.net/rfc/add_str_begin_and_end_functions/vote
> >
> > I have never set up a vote on doku-wiki so please let me know if I made
> > the vote incorrectly!
>
> It seems really unusual for voting to be on a separate page than the
> RFC. Can you move the doodle voting macro to a "Vote" section on the
> main RFC page?
>

Further to this, please follow the instructions at
https://wiki.php.net/rfc/howto. It has simple to follow steps detailing
exactly what to do.
Also, this RFC is *still* showing as "inactive" on the RFC list (
https://wiki.php.net/rfc) - anyone watching that page won't even know it
was back under discussion never mind in voting.


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

Re: [PHP-DEV] Re: Checkout phpdoc

[Peter Cowburn]

+Sascha

On Tue, 25 Jun 2019 at 08:46, Christoph M. Becker  wrote:

> On 25.06.2019 at 04:43, Arnold Daniels wrote:
>
> > I'm trying to checkout phpdoc using SVN, but I'm getting the error
> "Unexpected HTTP status 421 'Misdirected Request'".
> >
> > Is something broken? Or am I doing it wrong?
>

It looks like something is wrong due to the recently added CDN in front of
the SVN server.  If I make a request, I get the following response:

HTTP/1.1 421 Misdirected Request
Server: myracloud
Date: Tue, 25 Jun 2019 07:57:41 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 400
Connection: keep-alive
Expires: Tue, 25 Jun 2019 07:57:41 GMT
Cache-Control: max-age=0



421 Misdirected Request

Misdirected Request
The client needs a new connection for this
request as the requested host name does not match
the Server Name Indication (SNI) in use for this
connection.

Apache/2.4.25 (Debian) Server at svn.php.net Port 443


Sascha, any ideas?


> >
> > - Arnold
> >
> > $ svn co http://svn.php.net/repository/phpdoc/modules/doc-en phpdoc
> > A phpdoc/build.sh
> > U phpdoc
> >
> > Fetching external item into 'phpdoc/doc-base':
> > A phpdoc/doc-base/entities
> > A phpdoc/doc-base/entities/ISO
> > A phpdoc/doc-base/scripts
> > A phpdoc/doc-base/scripts/docgen
> > svn: warning: W175002: Unexpected HTTP status 421 'Misdirected Request'
> on
> '/repository/!svn/rvr/336013/phpdoc/doc-base/trunk/scripts/docgen/constructor.tpl'
> >
> > Fetching external item into 'phpdoc/en':
> > svn: warning: W175002: Unexpected HTTP status 421 'Misdirected Request'
> on '/repository/phpdoc/en/trunk'
> >
> > Checked out revision 347656.
> > svn: E205011: Failure occurred processing one or more externals
> definitions
> >
> > [Arnold Daniels - Chat @ Spike](
> https://www.spikenow.com/?ref=spike-organic-signature&_ts=1m6kq)
> [1m6kq]
>
> Nikita reported similar issues not long ago, but AFAIR these have been
> resolved; only sometimes intermittent checkout errors still occur.
> Please try to checkout again.
>
> Thanks,
> Christoph
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Using [ci skip]

[Peter Cowburn]

On Fri, 7 Jun 2019 at 12:09, Joe Watkins  wrote:

> Oh to be absolutely clear, I'm talking about commits that *only* touch
> these non-source files ...
>
> Cheers
> Joe
>
> On Fri, 7 Jun 2019 at 13:07, Joe Watkins  wrote:
>
> > Hi Marco,
> >
> > It wasn't a topic for discussion, it was a request to committers in
> > php-src.
> >
> > We do not need to run CI for NEWS changes, and we can definitely be sure
> > it doesn't effect the build.
> >
> > The same goes for other files like UPGRADING, UPGRADING.INTERNALS ...
> >
> > Under normal circumstances these files are not changed by themslves, but
> > occasionally, we have to correct one of these files and omitting [ci ski]
> > puts the build behind by up to an hour ...
> >
> > Cheers
> > Joe
> >
> > On Fri, 7 Jun 2019 at 13:02, Marco Pivetta  wrote:
> >
> >> Please avoid doing that:
> >>
> >>  1. Commit messages are for humans
> >>  2. You never know what can break, that's why it's "continuous" there
> >> (besides religious views around what "continuous integration" means)
> >>
> >> On Fri, Jun 7, 2019, 12:51 Joe Watkins  wrote:
> >>
> >> > Hi all,
> >> >
> >> > Just a friendly reminder that when we're committing changes to files
> >> that
> >> > do not contain source, test code, or build configuration, it's helpful
> >> to
> >> > include [ci skip] in the commit message. Omitting it can put our CI
> >> quite
> >> > far behind.
>

Is this documented somewhere? I'm not seeing it in the docs held in
php-src, nor a search of the wiki, for example.
Also, is this not something that the CI application(s) can be configured to
do for us?


> >> >
> >> > Cheers
> >> > Joe
> >> >
> >>
> >
>

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

[Peter Cowburn]

On Fri, 17 May 2019 at 09:15, Claude Pache  wrote:

>
>
> > Le 17 mai 2019 à 09:35, Peter Bowyer  a
> écrit :
> >
> > This could be a good time to make all blocks on the page collapsible,
> with
> > a "Collapse/Expand all" link added at the top.
> >
> > All added as progressive enhancement, so people with JavaScript disabled
> > see everything.
>
> There is no need for JavaScript: use  (as progressive
> enhancement, etc.)
>

How will that work for the cli (e.g. php -i)?


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

Re: [PHP-DEV] POC: Docker container with support for PHP and Nginx based on Debian Stretch

[Peter Cowburn]

Hi Jan,

On Tue, 30 Apr 2019 at 19:51, Jan Malaník  wrote:

> Hi,
> I'd like to introduce new variant of PHP Docker image with support for
> Nginx webserver based on Debian Stretch.
> I'm not sure if this is managed by you.


The Docker "Official image" for PHP is not maintained by the PHP Project.
>From the README file
 in their Git
repository:

This is the Git repo of the Docker "Official Image"
>  for php
>  (not to be confused with any official php
> image provided by php upstream). See the Docker Hub page
>  for the full readme on how to use this
> Docker image and for information regarding contributing and issues.
>
The full description from Docker Hub  is
> generated over in docker-library/docs
> , specifically in
> docker-library/docs/php
> .
>


> Can you please review the PR and give me comments?
> https://github.com/docker-library/php/pull/821


I'm sure the maintainers of that repository will look in on your Pull
Request soon, they are generally very responsive from my casual
observations.


>
>
> Thank you Jan
>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Cowburn]

On Wed, 10 Apr 2019 at 11:44, G. P. B.  wrote:

> Hello Internals,
>
> As there have been no further comments the voting for my RFC [1] to
> deprecate PHP's
> short open tags has started and will run for two (2) weeks.
>

Firstly, I apologize for not mentioning this before the vote was opened.

Does the primary (it's probably not fair to call it that, for this RFC)
vote include changing the default (php -n) from On to Off? That's what is
specified in the very concise proposal section, so it seems reasonable to
assume it's the case, but I just want to be sure since the actual vote
question doesn't mention changing the default value.

With the current state of voting, it is looking like we could end up such
that we don't deprecate (and disable by default, maybe) the feature, but
jump straight to removing it.  That's not usually how feature removal
works.  It would've been better, IMO, to just take the proposal
("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short
open tags in PHP 8.0.") and make that a yes/no vote.

Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags
>

Re: [PHP-DEV] Re: [VOTE] RFC: Unbundle ext/wddx

[Peter Cowburn]

On Mon, 25 Feb 2019 at 11:29, Joe Watkins  wrote:

> Whoever creates the pecl package would be listed as maintainer, which may
> explain silence :)
>
> I'm not sure who has karma for creating repos on git.php.net either, I
> may ?
>

FYI: dsp bjori rasmus tyrael johannes nikic salathe


>
> Cheers
> Joe
>
> On Mon, 25 Feb 2019, 12:10 Christoph M. Becker,  wrote:
>
> > On 11.02.2019 at 19:42, Christoph M. Becker wrote:
> >
> > > On 31.01.2019 at 23:19, Christoph M. Becker wrote:
> > >
> > >> The voting on
> > >>
> > >>   
> > >>
> > >> has ended, and it has unanimously been decided (30:0) to remove (aka.
> > >> unbundle) ext/wddx; it has also been decided (19:4:3:2) to deprecate
> the
> > >> extension and move it to PECL.  Thanks to all voters!
> > >
> > > Could someone with sufficient karma please move ext/wddx (PHP-7.4+) to
> > > PECL/wddx?  (Also the respective info in README.RELEASE_PROCESS[2]
> could
> > > need some update.)
> >
> > Anyone?  I guess I have sufficient karma to do the actual move, but
> > someone would have to set up PECL/wddx in the first place.
> >
> > --
> > Christoph M. Becker
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Wiki account gone missing?

[Peter Cowburn]

On 11 September 2018 at 16:22, Colin O'Dell  wrote:

> Hello Internals,
>
> I seem to be unable to access my wiki account (colinodell /
> colinod...@php.net).  My credentials are not being accepted and the
> password reset functionality does not recognize my username.  I am

therefore unable to manage my RFCs or draft a new one. (My credentials
> aren't working on bugs.php.net either, but I haven't done anything there
> in
> a while so I'm not too concerned about not having access to that.)
>
> Any thoughts on how to resolve this?  If this list is not the correct place
> to seek support then I'd appreciate if somebody could point me in the right
> direction :)
>

Since you have a php.net account, the password reset page is at
https://master.php.net/forgot.php (which I hope works).

As for asking for help when one of the websites appears broken, the first
port of call is generally php-webmas...@lists.php.net but no-one will rip
your arm off for posting to internals instead.


>
> Thanks!
>
> Colin O'Dell
> colinod...@gmail.com / colinod...@php.net
>
> --
> Colin O'Dell
> colinod...@gmail.com
> https://www.colinodell.com
>

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

[Peter Cowburn]

On 17 June 2018 at 20:43, Stanislav Malyshev  wrote:

> Hi!
>
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_ejkxtensions
> 
>
> The vote ends 2018-06-26 23:59 PDT.
>
> I have added some discussion about active maintainers and abandonment
> procedures, this can be refined further later. I also kept the list of
> the candidates as-is for now, but I will update it soon and probably
> make a separate wiki page for maintaining it. Please note this list is
> not part of the vote (the vote is on the process, not specific list
> which will change all the time).
>

Can anyone point me at the discussion thread for the revival of this RFC?
On the mailing list there have been a small number of mails broadly about
extensions and maintainers, and it looks like the RFC was only edited a few
days ago, but I feel like a dummy and can't find the "I'd like to revive
this RFC" thread at all.


>
> Thanks,
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RE: Requesting php-src Karma

[Peter Cowburn]

On 26 January 2018 at 20:02, Anatol Belski  wrote:

> Hi,
>
> > -Original Message-
> > From: Thomas Punt [mailto:tp...@hotmail.co.uk]
> > Sent: Thursday, January 25, 2018 11:41 PM
> > To: PHP internals list 
> > Subject: [PHP-DEV] Requesting php-src Karma
> >
> > Hi internals,
> >
> >
> > I'd like to request for php-src karma for my account (tpunt) in order to
> help
> >
> > with the handling of PRs on GitHub. Having been contributing to PHP for
> >
> > a few years now, I feel like I've got the hang of things well enough to
> make
> >
> > more of an impact to the project now.
> >
> I've first seen Thomas' contributions over two years ago at his early
> efforts to document PHP 7.0 features. At least from that point on, he made
> contribution to both doc and the core codebase through various pull
> requests and reviews. Based on his continuous and prudent participation,
> I'd see it as adequate to provide Thomas with the direct access to php-src.
> He is a valuable PHP contributor in point of fact.
>

Seconded. Thomas is a valuable contributor to PHP and I'm more than happy
to bump his commit karma to include php-src (and, indeed, have done so [1]).
Thomas, thank you for your involvement in the project so far!

[1] http://svn.php.net/viewvc?view=revision=343955


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

Re: [PHP-DEV] RE: High resolution timer function

[Peter Cowburn]

On 2 January 2018 at 10:43, Anatol Belski  wrote:

> Hi,
>
> > -Original Message-
> > From: Anatol Belski [mailto:weltl...@outlook.de] On Behalf Of Anatol
> Belski
> > Sent: Saturday, December 16, 2017 3:03 PM
> > To: internals@lists.php.net
> > Cc: Niklas Keller 
> > Subject: [PHP-DEV] High resolution timer function
> >
> > Hi,
> >
> > I would like to propose a function for high resolution monotonic timing.
> There
> > was discussions about this before and a PR https://github.com/php/php-
> > src/pull/2368 which has issues and was abandoned. I've filed
> > https://github.com/php/php-src/pull/2976 with some reworked
> > implementation.
> >
> > A monotonic timer can be usable in several situations besides
> benchmarking.
> > Having a simple functionality like this in the core should be a useful
> addition. The
> > current approach is a function returning array of [seconds, nanoseconds]
> and
> > optionally returning full nanosecond number as int on 64-bit or float on
> 32-bit.
> > The first way is the most portable. Quite a few platforms are already
> supported
> > by the current implementation.
> >
> > IMHO it should be fine to have a function like this in the core, perhaps
> also a few
> > helper functions could be useful, too. I would like to pursue 7.3 with
> this. Please
> > lets check for any concerns in general or with implementation, naming,
> etc.
> >
> If there are no further comments or objection, I would like to merge this
> patch anytime soon and see to add a couple of helper functions for
> diff/compare.
>
>
Why is this bypassing the RFC process?


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

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

[Peter Cowburn]

On 5 December 2017 at 13:57, Christoph M. Becker  wrote:

> On 05.12.2017 at 14:34, Pedro Magalhães wrote:
>
> > On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter <
> johan...@schlueters.de>
> > wrote:
> >
> >> 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?


I went through the outstanding "doc" group requests, there are currently
only 2 of those now remaining (I'm waiting on replies to emails for those
two).

Of the other two groups, there are currently 11 for the "php" group and 78
for the "pecl" group.


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

I didn't tackle this, but I have changed master so it that shows the "note"
that folks enter when applying for their account, to make it easier/quicker
to scan the list (e.g. for spam, and for me to find the "[group: doc]"
requests).


> >>
> >> 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===0=
> >> 0=20=1 (I believe this is visible to all @php.net
> >> account holders)
> >
> > 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.
>
> An additional issue is that many account requests are made for PECL
> accounts as well, and not everybody who has karma to approve or reject
> VCS account requests has karma to handle PECL account requests.

Furthermore, while some have karma to approve VCS accounts, they may not
> have karma to grant karma – so approving the accounts without granting
> actual karma does not really make sense.
>

You're right there, the two (approving an account, granting the appropriate
commit karma) should almost always be done at the same time. Anyone looking
to help with the account requests should have SVNROOT karma, or ask for it.
:)


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

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes (voting restarted)

[Peter Cowburn]

On 2 November 2017 at 11:35, Thomas Punt  wrote:

> Hi all,
>
>
> > I would add that this is particularly important on an RFC with two or
> more votes. On most RFCs, the voting question is implied to be "accept the
> change/feature as described above", but as soon as you have two votes, it's
> important to be clear which parts of the proposal are covered by each vote.
>
>
> As per feedback here, I have updated the first voting question for
> additional clarification. This has restarted the vote for the first
> question only. The second vote will continue as normal, and both will still
> end on the same date (November 15th).
>
>
Link to RFC: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes


>
> Sorry for the inconvenience.


>
> -Tom
>

Re: [PHP-DEV] [RFC] [Discussion] Allow a trailing comma in function calls

[Peter Cowburn]

On 24 October 2017 at 17:14, Sara Golemon <poll...@php.net> wrote:

> On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn <petercowb...@gmail.com>
> wrote:
> > I know it's late in the game, but I have a quick question. This RFC
> > includes a couple of "Not really a function" functions (namely isset()
> and
> > unset()) that will also be able to have a trailing comma, but I'm failing
> > to find the discussion on including "not really a function" calls in this
> > RFC. Why were those specific non-functions choices included? Why only
> those?
> >
> I'd guess because those are the only constructs which appear
> function-like *and* exhibit variadic behavior.
> empty/die/exit/print/require/include/require_once/include_
> once/__HALT_COMPILER
> don't have a variadic mode so allowing trailing commas in them would
> be pointless.
>

That's a fair point, then maybe we should consider declare() too?  Also, I
know that "echo" is a "doesn't even look like a function" but can that be
considered as if we're changing any language constructs at all in this RFC,
then that might benefit too.  Note, I'm just saying "consider" on purpose,
rather than suggesting any change to the RFC actually be made.


>
> -Sara
>

Re: [PHP-DEV] [RFC] [Discussion] Allow a trailing comma in function calls

[Peter Cowburn]

On 7 October 2017 at 19:34, Sammy Kaye Powers  wrote:

> Hello internals friends!
>
> The RFC to allow a trailing comma in function calls is up for discussion:
>
> https://wiki.php.net/rfc/trailing-comma-function-calls
>
> Summary:
>
> - Targets PHP 7.3
> - The previous vote on this combined function calls & declarations in
> the same vote (my bad!)
> - This RFC affects function calls only, not declarations
>

I know it's late in the game, but I have a quick question. This RFC
includes a couple of "Not really a function" functions (namely isset() and
unset()) that will also be able to have a trailing comma, but I'm failing
to find the discussion on including "not really a function" calls in this
RFC. Why were those specific non-functions choices included? Why only those?


> Thanks,
> Sammy Kaye Powers
> sammyk.me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] list server broken -> Fwd: ezmlm warning

[Peter Cowburn]

On 24 July 2017 at 22:55, li...@rhsoft.net  wrote:

> what is that for nosense?
>
> "550-Spammy URLs in your message" is for sure *not* a response from our
> mailserver sicne i am the guy who implemented the spamfilter and knows
> every single possible reject message
>

That message looks like it was as a result of *our* (lists.php.net's)
system bouncing the message (due to hitting one of the spam filter rules)
when trying to send a mail to you. I had a similar warning mail at the same
time for message #98535 which was a commit notification email [1].  This
seems to happen from time to time on seemingly random, completely innocuous
messages.

[1] http://news.php.net/php.cvs/98535


>
>  Weitergeleitete Nachricht 
> Betreff: ezmlm warning
> Datum: 24 Jul 2017 21:38:47 -
> Von: php-cvs-h...@lists.php.net
> An: li...@rhsoft.net
>
> Messages to you from the php-cvs mailing list seem to
> have been bouncing. I've attached a copy of the first bounce
> message I received.
>
> :
> 76.75.200.58 failed after I sent the message.
> Remote host said: 550-5.7.1 mail rejected by policy.  SURBL hit
> 550-Spammy URLs in your message
> 550 See http://master.php.net/mail/why.php?why=SURBL
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Namespaces in Core

[Peter Cowburn]

On 6 February 2017 at 17:21, Fleshgrinder  wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>

I don't often chime in on the internals list, so please excuse this
interruption.  Slinking in a vote which essentially is about adopting
namespaces in core, via new library RFC, is not the way to go about
changing our coding standards.  In short, I don't want to the see the
situation where this extension gets merged in to 7.2 (which it should be
:)) only to have someone ask, "what about the 'php' top-level namespace?"
and we all shrug and mutter, "too late" under our breaths.


>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Unsubscribe request

[Peter Cowburn]

On 11 January 2017 at 13:42, Javier Rubio  wrote:

> Hello,
>
> Can you please unsubscribe my email for that list?
>

Unsubscription is self-service. The two easiest ways to unsubscribe are:
1. Send an email to internals-unsubscr...@lists.php.net from the subscribed
email address
2. or, Fill out the form at http://php.net/mailing-lists.php


>
> Thank you in advance
>
> Regards
>
> Javier
>

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

[Peter Cowburn]

On 19 November 2016 at 10:45, Pierre Joye  wrote:

> On Nov 19, 2016 11:34 AM, "Joe Watkins"  wrote:
> >
> > Morning Pierre,
> >
> > Sorry, but yes.
> >
> > http://wiki.php.net/rfc/voting
> >
> > > There'd be a minimum of 2 weeks between when an RFC that touches the
> language is brought up on this list and when it's voted on is required.
> Other RFCs might use a smaller timeframe, but it should be at least a week.
>
> Seriously Joe, this is ridiculous. You are forcing a shorter period of time
> for something that does affect PHP at a whole.
>
> Be fair and let anyone raises their feedback.
>

Ignoring whether this RFC "touches the language" (phrasing I've always
taken issue with) and as such *requires* a two-week discussion period. I
think this particular RFC should be given two weeks, or longer, for
everyone to have their say.

Given that it is Thanksgiving next week, for purely practical reasons, I
think it necessitates a *longer* discussion period (than one week) as
interested parties may simply not be around at all. For a process-related
RFC such as this, forcing a one-week discussion period when a large number
of folks mightn't even be looking at the list, reads as irresponsible, to
me at least.

Regards,
Peter (who apologises in advance for poking the bear)

Re: [PHP-DEV] Re: VCS Account Request: emir

[Peter Cowburn]

On 18 November 2016 at 14:33, PHP Group  wrote:

> VCS Account Approved: emir approved by cmb \o/
>
>
Why? We don't even know what karma he's going to need. There's very little
point in having an account without that.


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

Re: [PHP-DEV] VCS Account Request: emir

[Peter Cowburn]

On 10 November 2016 at 16:41, Christoph M. Becker  wrote:

> On 10.11.2016 at 15:32, Dejan Marjanovic wrote:
>
> > Please approve this request. @salathe @bjori
> >
> > On Fri, Sep 16, 2016 at 3:19 PM, Emir Beganović <
> beganovic.e...@gmail.com>
> > wrote:
> >
> >> Contributing to documentation and php.net
>
> It would be great to have some references; maybe some pull requests or
> some patches submitted via . :-)
>
>
Hi Emir. As Christoph mentioned, it would be good to hear a little more
about your interest in the project, in particular which areas you are
wanting to work on. Mostly that's so whoever is handing out commit karma
knows which repositories to give you access to.  If you have submitted any
patches so far, that would be good to know as well.


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

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Peter Cowburn]

On 10 November 2016 at 10:38, Joe Watkins <pthre...@pthreads.org> wrote:

> Morning Peter,
>
> > I'll put RFC: On hold, then apply patch, draft some info in RFC and then
> set up new voting.
>
> Just a few messages up from here ...
>
> Would you prefer a new thread to make that announcement (I think it may be
> better) ?
>

No, it's fine IMO (and is the norm) to just have a message in the [VOTE]
thread. I simply missed Michał saying he was closing the vote, when
skimming the thread this morning, so thanks for pointing it out. :)


>
> Cheers
> Joe
>
> On Thu, Nov 10, 2016 at 9:52 AM, Peter Cowburn <petercowb...@gmail.com>
> wrote:
>
>>
>>
>> On 10 November 2016 at 09:11, Niklas Keller <m...@kelunik.com> wrote:
>>
>>> 2016-11-09 21:53 GMT+01:00 Christoph M. Becker <cmbecke...@gmx.de>:
>>>
>>> > On 09.11.2016 at 17:28, Joe Watkins wrote:
>>> >
>>> > > I want to explain why I voted no on this:
>>> > >
>>> > > I think it's significantly less useful without variance,
>>> variance is
>>> > > something that is usually difficult to achieve in PHP, but not for
>>> this
>>> > > feature in particular.
>>> >
>>> > Can you please elaborate what you mean with variance?  I see some
>>> > practical use cases for covariance of a method with return type object,
>>> > but I don't see how contravariance could be achieved for parameters of
>>> > type object.
>>> >
>>> > If your suggestion is only about invariance of object return types, I'm
>>> > not sure if this very special case would make sense (for consistency
>>> > reasons).
>>> >
>>>
>>> We already have it for iterable -> array. We would have it for all other
>>> types if there wouldn't be an implementation issue.
>>>
>>> Regards, Niklas
>>>
>>> Cheers,
>>> > Christoph
>>> >
>>> > > I absolutely want it, but I want it to be properly useful.
>>> > >
>>> > > If the RFC were halted and patched to include variance, I'd +1
>>> it.
>>> > >
>>> > > Cheers
>>> > > Joe
>>> > >
>>> > > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>>> <michal@brzuchalski.
>>> > .com>
>>> > > wrote:
>>> > >
>>> > >> Hi everyone,
>>> > >>
>>> > >> Two weeks have passed since this RFC was put to discussion here.
>>> > >>
>>> > >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>>> > >>
>>> > >> Voting starts today, 2016-11-06, and will close after two weeks on
>>> the
>>> > >> Sunday 2016-11-20 at midnight.
>>> > >>
>>> > >> The RFC and voting widget can be found here:
>>> > >> https://wiki.php.net/rfc/object-typehint
>>>
>>
>> The vote appears to be closed right now, did I miss an announcement?
>>
>>
>>>
>>> > >>
>>> > >> It's a normal 2/3 majority required vote.
>>> > >>
>>> > >> Thanks!
>>> > >> --
>>> > >> regards / pozdrawiam,
>>> > >> --
>>> > >> Michał Brzuchalski
>>> > >> about.me/brzuchal
>>> > >> brzuchalski.com
>>> > >>
>>> > >
>>> >
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>
>>
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Peter Cowburn]

On 10 November 2016 at 09:11, Niklas Keller  wrote:

> 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>
> > On 09.11.2016 at 17:28, Joe Watkins wrote:
> >
> > > I want to explain why I voted no on this:
> > >
> > > I think it's significantly less useful without variance, variance
> is
> > > something that is usually difficult to achieve in PHP, but not for this
> > > feature in particular.
> >
> > Can you please elaborate what you mean with variance?  I see some
> > practical use cases for covariance of a method with return type object,
> > but I don't see how contravariance could be achieved for parameters of
> > type object.
> >
> > If your suggestion is only about invariance of object return types, I'm
> > not sure if this very special case would make sense (for consistency
> > reasons).
> >
>
> We already have it for iterable -> array. We would have it for all other
> types if there wouldn't be an implementation issue.
>
> Regards, Niklas
>
> Cheers,
> > Christoph
> >
> > > I absolutely want it, but I want it to be properly useful.
> > >
> > > If the RFC were halted and patched to include variance, I'd +1 it.
> > >
> > > Cheers
> > > Joe
> > >
> > > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski  > .com>
> > > wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> Two weeks have passed since this RFC was put to discussion here.
> > >>
> > >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
> > >>
> > >> Voting starts today, 2016-11-06, and will close after two weeks on the
> > >> Sunday 2016-11-20 at midnight.
> > >>
> > >> The RFC and voting widget can be found here:
> > >> https://wiki.php.net/rfc/object-typehint
>

The vote appears to be closed right now, did I miss an announcement?


>
> > >>
> > >> It's a normal 2/3 majority required vote.
> > >>
> > >> Thanks!
> > >> --
> > >> regards / pozdrawiam,
> > >> --
> > >> Michał Brzuchalski
> > >> about.me/brzuchal
> > >> brzuchalski.com
> > >>
> > >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Set object properties inline

[Peter Cowburn]

On 1 June 2016 at 03:15, Jesse Schalken  wrote:

> Hi internals,
>
> I often have code dealing with plain old PHP objects with properties and no
> methods, either as a substitute for keyword arguments, or to represent a
> JSON or YAML document for a web service, configuration file or schemaless
> database.
>
> At the moment, instantiating an object and setting public properties
> requires a temporary variable for each object in the structure:


> $obj1 = new Obj1();
> $obj1->prop1 = ...;
> $obj1->prop2 = ...;
>
> $params = new FooParams();
> $params->prop1 = ..;
> $params->prop2 = ...;
> $params->prop3 = $obj1;
>
> $this->fooMethod($arg1, $arg2, $params);
>
>
> For large structures, this gets verbose very quick. There is a good example
> of this here
> <
> https://github.com/jesseschalken/fail-whale/blob/72870b37c4c21d19f17324a966344ec476b432a7/src/FailWhale/Introspection.php#L22
> >
> involving
> 18 unnecessarily variables.
>
> I can remove the local variables by defining setters for all the
> properties:
>
> $this->fooMethod(
>
> $arg1,
> $arg2,
> (new FooParams())
>
> ->setProp1(...)
>
> ->setProp2(...)
>
> ->setProp3((new Obj1())
>
> ->setProp1(...)
>
> ->setProp2(...))
>
> );
>
>
> But now for each property I have to spend an extra 3-5 lines of code
> defining a setter, which is more code than it saved (unless the class is
> used heavily enough).
>
> I could define __construct() taking every property as a parameter, but then
> each property has to be mentioned another three times (four times with a
> doc comment), and the type twice:
>
> class FooParams {
>
> public int $prop1;
> // ...
>
>
> public function __construct(
> int $prop1
> // ...
> ) {
>
> $this->prop1 = $prop1;
> // ...
>
> }
>
> }
>
>
> and where the object is constructed, it isn't immediately visible what the
> meaning of each positional parameter is without some IDE assistance (eg
> Ctrl+P in PhpStorm), and only specifying some parameters requires filling
> preceding ones with defaults.
>
> I could also define the __call() method to automatically expose setters,
> but then IDEs and static analysis can't understand what's going on (it
> can't see that those methods exist, what their parameters are and what they
> return). @method doc comments on the class help, but that's another line
> for every property which I have to manually keep in sync with the real
> properties.
>
> It would be great if there was a simple shorthand syntax for setting
> properties on an object in-line, without needing to extract a variable:
>
> $this->fooMethod(
> $arg1,
> $arg2,
> new FooParams() {
> prop1 = ...,
> prop2 = ...,
> prop3 = new Obj1() {
> prop1 = ...,
> prop2 = ...,
> },
> }
> );
>

While it's not as concise as your example, anonymous classes can do this
already after a fashion.

$this->fooMethod(
$arg1,
$arg2,
new class() extends FooParams {
// Constructor because prop3's value isn't a constant expression
function __construct() {
$this->prop1 = '...';
$this->prop2 = '...';
$this->prop3 = new class() extends Obj1 {
public $prop1 = '...';
public $prop2 = '...';
};
}
}
);


>
>
> This way the structure can be written directly in the code as an expression
> and FooParams and Obj1 remain simple containers for properties.
>
> The grammar might look like (I haven't used bison/yacc before):
>
> expr_without_variable:
> /* ... */
> |   expr '{' inline_set_properties '}'
> ;
>
> inline_set_properties:
> /* empty */
> |   identifier '=' expr
> |   identifier '=' expr ',' inline_set_properties
> ;
>
>
> (Although I think that would conflict with the alternative $var{8} syntax
> for array/string offset.)
>
> Has this been explored before? What problems can you foresee (or have been
> foreseen) with such a feature?
>
> Thanks
>

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

[Peter Cowburn]

On 26 April 2016 at 17:48, Julien Pauli  wrote:

> On Tue, Apr 26, 2016 at 6:37 PM, Michael Wallner  wrote:
> > On 26/04/16 17:59, Anatol Belski wrote:
> >> Hi,
> >>
> >> herewith I would like to call everyone to go vote for the 7.1 RMs team.
> The
> >> poll is opened under
> >>
> >> https://wiki.php.net/todo/php71
> >>
> >> The vote starts on 2016-04-26 and end on 2016-05-03 (both at a time
> 6pm).

>
> > Thanks!
> >
> > PS: If anyone is wondering WTF is going on (like I did), have a look at
> > the (recent messages of the) "PHP 7.1 roadmap" thread!
>
> WTF is going on ?  :D
>
> We are in May (in few days), and still got no 7.1 RM !
>
> Not bad, I'm not complaining nor urging the situation but if we want a
> 7.1 GA in December (that would be one year after 7.0);
> then we need to alpha at a minimum of 3 months before (October), that
> beeing a minimum, I'd suggest to better alpha end of summer
> (September).
>
> So, now decisions and organization should be taken about opened RFC,
> etc..., then branch 7.1 off when needed.
>
> Aka : some 7.1 specific job is showing up slowly, and we need some
> souls to take care of it, helped by old souls ;-)
>

Am I correct in understanding that no further candidates or volunteers for
the position will be considered at this time?


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

Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline

[Peter Cowburn]

On 13 January 2016 at 13:16, Bob Weinand  wrote:

> I agree,
>
> no votes should be meaning  "I want as less as possible support".
> Counting it that way would make it up for a tie and us choosing the most
> restrictive schedule as a result.
> (Interpreting it like "you need 50%+1 of the total to get it extended so
> far".)
>

As the RFC describes, the "no votes" were voting for "no change", i.e. the
8 month + 1 year schedule.

The second poll was conditional on having voted "yes" in the first poll.
There were two voters who didn't vote "yes" for the first poll who voted on
the second poll, but as they chose different options the conclusion doesn't
change.



>
> Hence Security Support until Dec 31 2017.
>
> Bob
>
> > Am 13.01.2016 um 14:02 schrieb Joe Watkins :
> >
> > The no votes should be counted as votes for option one schedule.
> >
> > Which makes the vote a tie, and if any changes are going to be made, we
> > should be using option 1 schedule, not 2 ...
> >
> > Cheers
> > Joe
> >
> > On Wed, Jan 13, 2016 at 11:51 AM, Zeev Suraski  wrote:
> >
> >> All,
> >>
> >> The vote has been closed.  It was approved 42 to 2 (95.5% in favor).
> >> There was a close race between the two available extended schedules, and
> >> the one selected is Active Support until December 31st 2016, and
> Security
> >> Support until December 31st 2018.
> >>
> >> Thanks to everyone who participated & voted!
> >>
> >> Zeev
> >>
> >> From: Zeev Suraski
> >> Sent: Tuesday, January 05, 2016 11:52 AM
> >> To: PHP internals 
> >> Subject: [RFC] [VOTE] PHP 5's Support Timeline
> >>
> >> Hopefully mostly everyone is back from the holidays by now, the vote is
> >> now open for the PHP 5 Support Timeline RFC:
> >>
> >> https://wiki.php.net/rfc/php56timeline#vote
> >>
> >> Voting ends January 13th 2016 at 10:00am GMT.
> >>
> >> Thanks!
> >>
> >> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Anonymous voting on wiki

[Peter Cowburn]

On 11 January 2016 at 12:14, Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> > Sent: Sunday, January 10, 2016 12:00 AM
> > To: Andrea Faulds ; internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
> >
> > Hi!
> >
> > > This seems useful. I do wonder whether we should use by default for
> > > RFCs. It's interesting to see how different people vote, and knowing
> > > who
> >
> > I think we talked about it, and decided not to do it. Anything changed?
> >
> > > One concern I have with the patch is that it doesn't appear (by my
> > > reading of the code) to show who voted. I think it's important to know
> >
> > This is intentional. Otherwise by taking snapshots of the page at regular
> > periods and seeing who voted and how the totals changed, one can deduce
> > each personal vote.
>
> I have no idea if it's related, but is there any chance the patch caused
> some older votes to be broken - at least in how they're displayed?
> Case in point:
> https://wiki.php.net/rfc/voting/vote


The patch for this PR has not been merged, so no.

The linked page has been like that since April '14 and likely for some time
before then:
http://web.archive.org/web/20140411014209/https://wiki.php.net/rfc/voting/vote


>
>
> Zeev
>
>

Re: [PHP-DEV] INI_SCANNER_TYPED: New in PHP 5.6 or PHP 7?

[Peter Cowburn]

Hi Sebastian,

On 1 December 2015 at 09:11, Sebastian Bergmann  wrote:

>  According to UPGRADING [1], INI_SCANNER_TYPED was added in PHP 7:
>
>"- parse_ini_file():
> - parse_ini_string():
>   . Added scanner mode INI_SCANNER_TYPED to yield typed
>   .ini values."
>
>  However, the INI_SCANNER_TYPED constant already exists in
>  PHP-5.6 and seems to be actually used.
>

It was introduced in 5.6.1, as mentioned in the parse_ini_file() docs[1]
and in the 5.6 UPGRADING file [2]. Alas, it's not uncommon for older
NEWS/UPGRADING entries to mistakenly appear in later versions.


>
>  --
>  [1]
> http://git.php.net/?p=php-src.git;a=blob_plain;f=UPGRADING;hb=PHP-7.0.0
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[1] http://php.net/manual/en/function.parse-ini-file.php
[2] http://git.php.net/?p=php-src.git;a=blob_plain;f=UPGRADING;hb=PHP-5.6

[PHP-DEV] static:: and PHP 7 (from bug #70997)

[Peter Cowburn]

Hi internals,

I'm looking for some feedback on a change with regard to static::, which
has been present throughout the 7 branch.

Have a look-see at https://bugs.php.net/bug.php?id=70997

test();

?>

In PHP 7 it dumps true, in PHP 5 false.

I'm looking for info on when, where, why it was introduced, and ultimately
some clarification of:
a) was this intentional
b) it is going to stay (i.e. "not a bug")
c) some more to go on so I can document the change clearly

If there is already a line in NEWS/UPGRADING or a commit you can point me
to, that would be amazing.

Whatever tangents this topic wanders off on, I'd like to eventually pull it
back to the bug report mentioned above with one eye on formulating the docs
changes (if it's really "not a bug").

Cheers,

A docs guy.

[PHP-DEV] Re: static:: and PHP 7 (from bug #70997)

[Peter Cowburn]

On 30 November 2015 at 12:16, Peter Cowburn <petercowb...@gmail.com> wrote:

> Hi internals,
>
> I'm looking for some feedback on a change with regard to static::, which
> has been present throughout the 7 branch.
>
> Have a look-see at https://bugs.php.net/bug.php?id=70997
>
> 
> class A {
> const TEST = false;
> public function test() {
> var_dump(static::TEST);
> }
> }
>
> class B extends A {
> const TEST = true;
>
> public function test() {
> A::test();
> }
> }
>
> $b = new B;
> $b->test();
>
> ?>
>
> In PHP 7 it dumps true, in PHP 5 false.
>

Gah, this was inevitable!  In PHP 7 it dumps FALSE, in PHP 5 TRUE. Stupid
brain.


>
> I'm looking for info on when, where, why it was introduced, and ultimately
> some clarification of:
> a) was this intentional
> b) it is going to stay (i.e. "not a bug")
> c) some more to go on so I can document the change clearly
>
> If there is already a line in NEWS/UPGRADING or a commit you can point me
> to, that would be amazing.
>
> Whatever tangents this topic wanders off on, I'd like to eventually pull
> it back to the bug report mentioned above with one eye on formulating the
> docs changes (if it's really "not a bug").
>
> Cheers,
>
> A docs guy.
>
>

[PHP-DEV] PhpStorm Open Source Licenses 2015/16

[Peter Cowburn]

Hi folks,

It's that time of year again. If you are using our PhpStorm license, you've
probably been prompted about it expiring in December.  JetBrains have
kindly offered their open source license to us again, and as usual all
details are on the wiki*.

https://wiki.php.net/licenses/jetbrains/phpstorm

Cheers,

Peter

* As always, please do not pass on any information that is on that wiki
page.

[PHP-DEV] Re: [PHP-WEBMASTER] PhpStorm Open Source Licenses 2015/16

[Peter Cowburn]

On 8 November 2015 at 20:53, Christopher Jones <christopher.jo...@oracle.com
> wrote:

>
>
> On 9/11/2015 7:01 am, Peter Cowburn wrote:
>
>> Hi folks,
>>
>> It's that time of year again. If you are using our PhpStorm license,
>> you've
>> probably been prompted about it expiring in December.  JetBrains have
>> kindly offered their open source license to us again, and as usual all
>> details are on the wiki*.
>>
>> https://wiki.php.net/licenses/jetbrains/phpstorm
>>
>> Cheers,
>>
>> Peter
>>
>> * As always, please do not pass on any information that is on that wiki
>> page.
>>
>>
> Even without bias, I'm a bit uncomfortable seeing this on the mail list.
>

Find me another more appropriate place to pass this along, and I'll do so.
In the mean time, let's use what we've used for years... the mailing lists.


> But with bias: don't forget NetBeans is free: https://netbeans.org/


>
> --
> http://twitter.com/ghrd
>

[1] I did think about excluding internals because there's always some drama.

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

[Peter Cowburn]

On 13 October 2015 at 23:49, Andrea Faulds  wrote:

> Hi Adam,
>
> Adam Harvey wrote:
>
>> (Sorry Andrea, I'm picking on your e-mail because it's easiest, but
>> it's a general response to the thread.)
>>
>
> Ah, don't worry about it.
>
> I agree that we should do something, but I think we should alias.
>>
>> We allow both "int" and "integer" in settype() and we allow it in type
>> casting — the two other places where a user can specify a type for
>> conversion.
>>
>
> We also support 'real' and 'binary' in casts, but these are quite rare,
> and I think (int) is a lot more common than (integer), heck, the manual
> uses it.
>
> I still think it's a poor choice to not allow both in type
>> declarations: while I'm generally a fan of having one way to do
>> things, I believe that the inconsistency in the language is worse than
>> the potential ambiguity in style guides.
>>
>
> Well, we could support the full set of names (int, integer, long, float,
> double, real, string, binary, bool, boolean) everywhere, but this is a bit
> unruly. It's better to pick one and stick to it, and discourage the us of
> the others or slowly phase them out.


I'm going to keep beating this drum, but I disagree with that last
statement.  We *should* at the very least support both full and short names
for "int" and "bool": again, why stomp on people's muscle memory over
something so utterly trivial to support?  The only argument that I've
gleaned from this thread is "but, but, it's *inconsistent*" and that is not
something I disagree with at all. I simply prefer to support them, clearly
most others here don't.

An arbitrary code search shows that, for people currently documenting their
arguments with phpdoc, a non-trivial number of people choose the longer
terms for bool/int. [1] [2]



> Hell, _I_ still can't remember which out of "int" and "integer" is the
>> right one, and I've now written a decent amount of PHP 7 code _and_
>> wrote half of the documentation for this.
>>
>
This. So much this. Just like you, I keep typing "integer", and "boolean".
Maybe us folks on the documentation team have some mental deficiency that
the more internals folks don't have? (I'm only half-joking there.)


>
> The rule seems to be 'integer' in English, 'int' in code, for the most
> part.


I'd agree with "for the most part" but I disagree with that part being a
large enough part to ignore the other parts.


>
> Plus, if we error when "integer" is used, we've moved people's cheese
>> anyway (by disallowing the class name). Let's not compound that by
>> forcing them to do busywork.
>>
>
> I think this would drill into you that it's 'int' not 'integer' pretty
> quickly, so it wouldn't become annoying.


It's int. It's int. It's int. It's int.  For this to be resolved, at least
for me, personally, there's going to need to be a lot more drilling. I like
to think that I'm not alone in this respect, but maybe that's not the case.


>
>
>> Adam, who hopes that anecdote doesn't say more about his working
>> memory than the design of the language.
>>
>>
Peter, who is a little tired of the folks beating the "more errors please"
drum.


>
> PHP is a confusing behemoth, don't worry, you're not alone :)
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[1] "@param boolean"
https://github.com/search?l=php=%22%40param+boolean%22=searchresults=Code=%E2%9C%93
[2] "@param integer"
https://github.com/search?l=php=%22%40param+integer%22=searchresults=Code=%E2%9C%93

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

[Peter Cowburn]

On 12 October 2015 at 20:23, Andrea Faulds  wrote:

> Hi,
>
> As PHP 7 currently is, if you write this:
>
> public function foo(): integer {
> return 12;
> }
> $bar = foo();
>
> you'll get the following error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, integer returned
>
> Similarly, if you were to write this:
>
> public function foo(): boolean {
> return true;
> }
> $bar = $foo();
>
> you'd get this:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of boolean, boolean returned
>
> These are confusing and unhelpful error messages. The long-form names of
> types (integer, boolean) aren't accepted as type hints, only their
> short-form names (int, bool) are. Yet we didn't reserve the names 'integer'
> and 'boolean' so we could produce a helpful error message, so anyone who
> types these long names will have them interpreted as type hints for (likely
> non-existant) classes named 'integer' or 'boolean' respectively. That
> produces confusing error messages on its own, but worse, type hint errors
> use 'integer' and 'boolean' to describe the types of values expected or
> given. Together, these two issues mean you get the two incredibly confusing
> error messages above.
>
> This is not kind to the users of PHP. It will cause unneeded confusion.
> This isn't even a theoretical case, that first example was based on a real
> StackOverflow question.[0] Mistakenly typing 'integer' or 'boolean' instead
> of 'int' and 'bool' is not at all an unlikely error, especially since the
> PHP manual uses these in some places (we should probably fix that at some
> point, and make it use PHP's actual syntax for return types and variadics,
> but I digress...), and since the aforementioned type error messages use
> them.
>
> To avoid confusion, I would like it if we reserve 'integer' and 'boolean'
> alongside 'int' and 'bool', and make them produce an error if used. This
> would catch out mistakes with people writing the wrong name for the type
> hint, and as a bonus would prevent people from misreading typehints for
> classes which actually have thse names, as no class with that name would be
> allowed. However, we're getting close to release and this might force some
> people to rename classes again if changed, causing disruption, so we might
> not be able to do this.
>
> Alongside or instead of that, though, we can do two other things to make
> this situation better.
>
> First, we could make type error messages use 'int' and 'bool'. This feels
> somewhat wrong to me since integer and Boolean are the proper English names
> for the types. But we do use the short names in some other places, like
> var_dump, so this isn't so bad. This way, we get this slightly clearer
> error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, int returned
>
> Second, we could add a helpful note to the TypeError message when the type
> hint is for a class named 'integer' or 'boolean' and the value passed was
> an integer or Boolean, respectively. My patch (based on Anthony's original)
> for the earlier Scalar Type Hinting with Cast RFC did this. This would make
> things even clearer:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, int returned (did you mean to use the type hint 'int'?)
>

I'm sure the "hint" would will get certain nay-sayers' skins crawling.


>
> Even if we can't reserve the names, I hope we can do the two other
> suggestions in time for release.
>
> By the way, this situation is at least partly my fault. For PHP 7 I fixed
> zend_parse_parameters and userland type hint errors consistent with regard
> to type names: always 'integer', never 'long' (which only ever occured for
> the expectation, not what was actually given, bizarrely), and also always
> 'float', never 'double'. I also made sure is_int was an alias of is_long
> and not vice-versa. Alas, I made the mistake of picking 'int' over
> 'integer' and 'bool' over 'boolean'.
>
> Anyway, can we do something about this soon?
>

I would much rather we use the full names for these types across the board.

The manual uses them almost exclusively, and I'd hazard a bet that it is
many peoples' first choice when trying out the argument/return type
declarations.

Failing that, at least making them available as aliases is a good thing in
my book.  I never understood the reluctance to make use of all existing
names when the type declarations discussions were going on. Fact is, people
are going to type "double", "long", etc. in their declarations... why get
in their way?




>
> Thanks!
>
> [0]
> http://stackoverflow.com/questions/32665818/php-7-return-type-declarations-fatal-error
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

[Peter Cowburn]

On 13 October 2015 at 11:59, Andrea Faulds <a...@ajf.me> wrote:

> Hi Peter,
>
> Peter Cowburn wrote:
>
>> I would much rather we use the full names for these types across the
>> board.
>>
>
> I would mostly agree with you. Using the full English names whenever we're
> writing English, not code, makes sense. But we usually use int/float/etc.
> in code, like other languages do, and I don't see a good reason to change
> that.
>
> The manual uses them almost exclusively,
>>
>
> Not for type signatures it doesn't. It usually uses "int" and "bool".


I said "almost" for a reason. More clearly, we use the long names in prose
and by convention the short ones in the function prototypes.


>
>
> and I'd hazard a bet that it is
>> many peoples' first choice when trying out the argument/return type
>> declarations.
>>
>
> Yeah, and others will sometimes use them by 'mistake'. I know I certainly
> have. So we need to prevent this creating confusion.


I would say that more confusion will arise from trying to use something
that comes naturally (e.g. "integer") and getting an error, than having it
"just work".


>
>
> Failing that, at least making them available as aliases is a good thing in
>> my book.  I never understood the reluctance to make use of all existing
>> names when the type declarations discussions were going on. Fact is,
>> people
>> are going to type "double", "long", etc. in their declarations... why get
>> in their way?
>>
>
> I don't want to allow them as aliases, because it means another thing to
> add to style guides. Some people would use 'float', some 'double', some
> would use 'int', some 'integer', some 'long'. It'd be much cleaner to just
> pick one and stick with it. Types don't need multiple names.
>

So what if there is more than one way to say "hey, I want an integer here",
particularly when they're super-duper common terms that are used
everywhere. (I'm talking about "boolean" and "integer" specifically,
however if someone wants to use "long", or "double", or "real" then why the
hell stop them?


>
> However, as you mention, many people are used to the other variants. So
> I'd like to reserve them and throw an error if you use them. Much better
> than people typing 'function format_number(double $number, long $digits)`
> and getting bewildered when it doesn't work.
>

-1 to throwing an error, that's just completely the wrong direction in my
view. I'd much rather your example work.


>
> Thanks.
>
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Strings, invalid escape sequences and parse errors

[Peter Cowburn]

Happy Friday, internals!

Prior to PHP 7, any "invalid" escape sequences within strings (as far as I
can see) were ignored and the characters treated literally. For example:
"\xGG" ("broken" hex sequence) gives "\xGG", "\99" ("broken" octal
sequence) gives "\99", "\m" (not a recognised sequence at all) gives "\m"
and so on.

PHP 7 introduced a new escape sequence for unicode codepoints "\u{...}".
This deliberately breaks away from the pack and raises a Parse Error when
an escape sequence starting with "\u{" is not followed by the required
characters to make it a "valid" escape sequence (i.e. 1 to 6 hex characters
followed by a curly brace).

Why does \u{} behave differently for any other escape sequence? Because the
author prefers it that way,and indeed thinks all "invalid" escape sequences
should result in the same error. [pers. comm.]

The question I'd like to bring forward is: can we either:

a) change all other "invalid" escape sequences to be a parse error [that
would mean "\m" would raise a parse error!]

b) change \u{} to behave like any other escape sequence, by not raising a
parse error and instead keeping the literal characters

or c) tell me to keep quiet and accept the oddball behaviour, having quirks
is The PHP Way after all.

Either way, I'd like to see some resolution to this sooner rather than
later as we're very late in the PHP 7.0.0 game.

Cheers, and enjoy your weekends,

Peter

Re: [PHP-DEV] set_exception_handler catches all Throwables

[Peter Cowburn]

On 17 August 2015 at 15:24, Sebastian Bergmann sebast...@php.net wrote:

 Am 17.08.2015 um 16:00 schrieb Derick Rethans:
  Actually, I don't call this intended. This is just as much as a BC break
  as the original implementation where Errors where also Exceptions. IMO,
  set_exception_handler() should be changed - with my preference it not
  capturing Error, and instead have an additional set_throwable_handler().

  +1


What's the plan for set_exception_handler() regarding Throwables? Seeing as
we're now in the RC release phase I think this bone of contention should be
resolved one way or another as soon as we can.



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

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

[Peter Cowburn]

On 28 April 2015 at 14:24, Olivier Garcia oliviergar...@php.net wrote:

 Dear Internals,

 The Improved Error Callback Mechanism RFC is now in voting phase.

 You can cast your vote on the Wiki [1] and the according patch is
 available as a Pull Request [2].

 Vote will be open for two weeks, counting from today.


It's now 6 weeks later and the vote is still open, what is the actual
status of this RFC and its vote?



 Kind regards,


 [1] https://wiki.php.net/rfc/improved_error_callback_mechanism
 [2] https://github.com/php/php-src/pull/1247

 --
 Olivier Garcia

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

Re: [PHP-DEV] error git push - You have insufficient Karma for gtk-src.git!

[Peter Cowburn]

On 7 June 2015 at 14:14, Alexandre Pereira Bühler 
alexan...@simaoebuhler.com.br wrote:

 Kaplan,
 Good day,
 I already have karma to push in
 http://git.php.net/?p=web/gtk.git;a=summary
 See: https://people.php.net/user.php?username=buhlerax
 The problem is that the php-gtk project is half abandoned.
 And I do not want to leave the php-gtk project die.
 I made a correction on the project site by git. -
 http://git.php.net/?p=web/gtk.git;a=summary
 It's faster than waiting for someone to accept the changes on github.
 I believe I made a push on github and waited months before I gave up.
 I have an update on the project site. I will publish soon.
 Now I need to have karma enough to change the documentation and start the
 development of php-gtk3.
 We are standing in the php-gtk2 since 2008.
 Help me keep this project. Give me enough karma in:
 http://git.php.net/?p=doc/gtk.git;a=summary
 and
 http://git.php.net/?p=php/gtk-src.git;a=summary
 thank you


You have karma for those projects, which should mean that you can push to
them in a little while once the karma changes get synced.




 --
 Alexandre Pereira Bühler
 Linux User: 397.546

 Simão   Bühler Ltda (Infobrindes)
 http://www.simaoebuhler.com.br
 alexan...@simaoebuhler.com.br
 Telefone: (41) 3039-5428

 Infobrindes (Simão   Bühler Ltda)
 Brindes e material promocional.
 http://www.infobrindes.com.br
 ka...@infobrindes.com.br
 Telefone: (41) 3082-8667


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

Re: [PHP-DEV] Soft-reserve void class name

[Peter Cowburn]

On 19 May 2015 at 17:16, Levi Morrison le...@php.net wrote:

 I strongly disagree with this action. These types required an RFC; why
 should this be different? Also note that neither of the reserve
 typename RFC were unanimous.

 Furthermore, we are past the RFC stage. We are *supposed to already
 have an alpha* by now and we are proposing new changes?. Please stick
 to our established rules and release timetables as much as possible,
 thank you.


To be fair, this change does not change a single byte of code. It's just
adding another type to the reserved list (to be documented) in the
manual. Unless I'm mistaken.

If the above really is the case, then why not stick up an RFC and vote.?

P.S. I'm not 100% clear on the outcome of all of these votes on what is
reserved and whether any of those give warnings/etc. in PHP 7; maybe
someone could give me an executive summary off-list? :)



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

Re: [PHP-DEV] PDO Oracle driver

[Peter Cowburn]

cc-ing doc list

On 22 April 2015 at 10:40, Stelian Mocanita stelian.mocan...@gmail.com
wrote:

 Hello internals,

 I would like to ask what on your thoughts on removing the Oracle drive for
 PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
 at least since it's been experimental for a long time now, and it has long
 standing open bugs, such as:

 https://bugs.php.net/bug.php?id=37706
 https://bugs.php.net/bug.php?id=46728
 https://bugs.php.net/bug.php?id=60994

 I know that the extension is marked as experimental already but based on
 the current status, it's not even that and a significant amount of basic
 functionality is broken.

 Regards,
 Stelian

Re: [PHP-DEV] PDO Oracle driver

[Peter Cowburn]

On 22 April 2015 at 11:24, Peter Cowburn petercowb...@gmail.com wrote:

 cc-ing doc list

 On 22 April 2015 at 10:40, Stelian Mocanita stelian.mocan...@gmail.com
 wrote:

 Hello internals,

 I would like to ask what on your thoughts on removing the Oracle drive for
 PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
 at least since it's been experimental for a long time now, and it has long
 standing open bugs, such as:


From the documentation point of view:

Just because an extension is considered experimental, or indeed
unmaintained, is no reason to remove the extension from the manual.  We
have a bunch of extensions marked as experimental [1] or dead [2] and I
don't see why pdo_oci should be any different.



 https://bugs.php.net/bug.php?id=37706
 https://bugs.php.net/bug.php?id=46728
 https://bugs.php.net/bug.php?id=60994

 I know that the extension is marked as experimental already but based on
 the current status, it's not even that and a significant amount of basic
 functionality is broken.


Let's mark the extension as dead in the manual, as we do with other dead
extensions.



 Regards,
 Stelian



[1] bcompiler, blenc, dbplus, haru, memtrack, ming, paradox, pdo_4d,
pdo_oci, sca, sdodasrel, spl_types, svn, swish, vpopmail, xmlrpc
[2] classkit, fam, fdf, iisfunc, msession, nis, session_pgsql

Re: [PHP-DEV] PDO Oracle driver

[Peter Cowburn]

On 22 April 2015 at 11:40, Stelian Mocanita steli...@php.net wrote:

 Peter,

 I did not know about the documentation part, thanks for clearing that out.

 I would like to ask though, what is the benefit of having the dead
 extensions there?
 From my point of view, it does more harm than good having them in the
 manual
 (I am only referring here to extensions that never got to a production
 grade).

 On marking the extension as dead, how would we proceed in this case?


We have boilerplate text for marking PECL extensions as dead, and we would
use that again here.

However, I'd hold off on that until a decision (if any) has been made on
what to do with the extension itself, like moving it (back) to PECL. We
shouldn't be distributing a dead extension in the main php-src tree, nor
proclaiming an extension dead in the manual when that hasn't been
officially decided yet.



 Thank you,
 Stelian


 On Wed, Apr 22, 2015 at 12:34 PM, Peter Cowburn petercowb...@gmail.com
 wrote:



 On 22 April 2015 at 11:24, Peter Cowburn petercowb...@gmail.com wrote:

 cc-ing doc list

 On 22 April 2015 at 10:40, Stelian Mocanita stelian.mocan...@gmail.com
 wrote:

 Hello internals,

 I would like to ask what on your thoughts on removing the Oracle drive
 for
 PDO from the documentation (
 http://us1.php.net/manual/en/ref.pdo-oci.php)
 at least since it's been experimental for a long time now, and it has
 long
 standing open bugs, such as:


 From the documentation point of view:

 Just because an extension is considered experimental, or indeed
 unmaintained, is no reason to remove the extension from the manual.  We
 have a bunch of extensions marked as experimental [1] or dead [2] and I
 don't see why pdo_oci should be any different.



 https://bugs.php.net/bug.php?id=37706
 https://bugs.php.net/bug.php?id=46728
 https://bugs.php.net/bug.php?id=60994

 I know that the extension is marked as experimental already but based on
 the current status, it's not even that and a significant amount of basic
 functionality is broken.


 Let's mark the extension as dead in the manual, as we do with other
 dead extensions.



 Regards,
 Stelian



 [1] bcompiler, blenc, dbplus, haru, memtrack, ming, paradox, pdo_4d,
 pdo_oci, sca, sdodasrel, spl_types, svn, swish, vpopmail, xmlrpc
 [2] classkit, fam, fdf, iisfunc, msession, nis, session_pgsql

[PHP-DEV] To RFC or Not To RFC [was Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

[Peter Cowburn]

On 21 March 2015 at 08:14, Xinchen Hui larue...@php.net wrote:

 Hey:

 On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui larue...@php.net wrote:
  Hey:
 
  On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams a...@phcomp.co.uk
 wrote:
  On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote:
  On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
   Hi internals,
   Hi internals,
  
   The RFC to add a user-land function for an easy-to-use and reliable
   preg_replace_callback_array() in PHP is up for discussion:
   https://wiki.php.net/rfc/preg_replace_callback_array
  
   This proposes adding one function: `preg_replace_callback_array()`
 that
   is the better way to Implement when there are multiple patterns
 need to
   replace.
  
   I would love to hear your feedback! :)
   Any objections?
  
   I’ve sent this mail for four days, I don’t know if this RFC needs a
 vote.
   If you guys have no objections on this, please review the code and
 merge it,
   thanks.
 
  Nice job, i like the idea.
 
  I am not sure about a RFC or not. It somehow looks like a sane
  replacement for something we killed (with good reasons).
 
  Let see what the other think :)
 
  I used s/something/code/ge in a perl script that I wrote a few days
 ago. Very
  useful. It would have been a lot more work to do it another way.
 
  So: +1 to the ability to do this, regardless of what mechanism is
 eventually chosen.
 
  I also +1 for this.
 
  if there is no objections raises, I am going to merge it tomorrow..
 merged

 thanks




Whoa, hold on there a second.

An RFC was created, presumably intending to follow that line of procedure.
Then Xinchen comes along and puts a middle finger up to the whole process,
reverts back to the old if no-one complains by tomorrow, merge it
approach, then does the merge.

I'm all for avoiding the potentially unnecessary red tape of the RFC
process. Particularly for small, standalone changes like this. I fear there
are other who aren't so lenient.

Thoughts?..




 
  thanks
 
  --
  Alain Williams
  Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer,
 IT Lecturer.
  +44 (0) 787 668 0256  http://www.phcomp.co.uk/
  Parliament Hill Computers Ltd. Registration Information:
 http://www.phcomp.co.uk/contact.php
  #include std_disclaimer.h
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
  --
  Xinchen Hui
  @Laruence
  http://www.laruence.com/



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/

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

Re: [PHP-DEV] [VOTE] Reserve even more type hints

[Peter Cowburn]

On 17 March 2015 at 08:02, Sanford Whiteman figureone...@gmail.com wrote:

  rather than having a single untyped parameter amongst typed ones


 Yes, when experimenting with strict types, I'd rather move things in and
 out of 'mixed' than remove the notation completely.  Like you said, 'mixed'
 means, I've reviewed this area and concluded it needs to be dynamic.

 Also, maybe I missed this upthread, but are the docs still going to refer
 to 'mixed'?


Yes.



 -- Sandy

Re: [PHP-DEV] Voting irregularities

[Peter Cowburn]

On 15 March 2015 at 15:23, Levi Morrison le...@php.net wrote:

 On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner m...@php.net wrote:
 
  On 15 03 2015, at 15:19, Anthony Ferrara ircmax...@gmail.com wrote:
 
  All,
 
  I ran some numbers on the current votes of the dual-mode vote right
  now. There were a number of voters that I didn't recognize. So I
  decided to pull some stats.
 
  The following voters never voted before the dual-mode RFC went up:
 
  dom - no
  eliw - no
  kguest - yes
  kk - no
  nohn - no
  oliver - yes
  richsage - yes
  sammywg - no
  spriebsch - no
  srain - no
  theseer - no
  zimt - no
 
  Some of these names I recognize from list (sammywg and eliw), but many
 I do not.
 
  The interesting thing happens when you look at the voting direction.
 
  Currently, the RFC is slightly losing 70:37 (65.4%).
 
  If we look at percentages, 4.2% of yes voters have never voted in a
  prior RFC. But a whopping 24.3% of no voters have never voted before.
 
  If we adjust the votes to remove these never voted accounts, it
  stands at 67:28. Which is 70.5%. Which is basically where the vote was
  prior to the competing RFC opening.


Extra! Extra! Read all about it: voters come out of the woodwork to vote on
contentious issues!

(Sorry, just poking fun...)


 
  I'm not saying that all of these are bad votes. Nor that they
  shouldn't be counted. I think it does raise a significant question
  around the voting practices.
 
  Something that I think we need to discuss as a group.
 
  So consider that discussion open.
 
  Jeez, that is becoming ridiculous. So, if you’re that good in counting,
 how many did not vote before STHv0.3?

 Is there a way to check when someone got a php.net account/karma?


The user page [1] on master.php.net shows when they applied for an account
(and sometimes other notes), which is generally roughly the same time as
getting an account within days/weeks.

[1] E.g. https://master.php.net/manage/users.php?username=salathe
 (accessible only to folks with @php.net accounts)



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

Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function

[Peter Cowburn]

On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote:

 Hi internals,

 The RFC to add a user-land function for an easy-to-use and reliable
 preg_replace_callback_array() in PHP is up for discussion:
 https://wiki.php.net/rfc/preg_replace_callback_array

 This proposes adding one function: `preg_replace_callback_array()` that
 is the better way to Implement when there are multiple patterns need to
 replace.

 I would love to hear your feedback! :)


Could you add a paragraph or two explaining the reasons for choosing this
particular proposal?
Some examples of what I would like to read:
 - why we can't do preg_replace_callback($array_of_regexes,
$array_of_callbacks, $subject)
 - why not preg_replace_callback($array_of_regex_to_callback_pairs,
$subject)
 - why not pass the regex used to the callback, as per Laruence's earlier
RFC

And give a few links to historical discussions in the same sort of area?
E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and
its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq).




 Any objections?


 —
 Best,
 Wei Dai

Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function

[Peter Cowburn]

On 16 March 2015 at 14:59, Xinchen Hui larue...@php.net wrote:

 Hey:

 On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com
 wrote:
  On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote:
 
  Hi internals,
 
  The RFC to add a user-land function for an easy-to-use and reliable
  preg_replace_callback_array() in PHP is up for discussion:
  https://wiki.php.net/rfc/preg_replace_callback_array
 
  This proposes adding one function: `preg_replace_callback_array()` that
  is the better way to Implement when there are multiple patterns need to
  replace.
 
  I would love to hear your feedback! :)
 
 
  Could you add a paragraph or two explaining the reasons for choosing this
  particular proposal?
  Some examples of what I would like to read:
   - why we can't do preg_replace_callback($array_of_regexes,
  $array_of_callbacks, $subject)
 array() also could be a valid callback.. (array(clasname, methodname)).
   - why not preg_replace_callback($array_of_regex_to_callback_pairs,
  $subject)
 there are also $limit, $count argument could be used.
   - why not pass the regex used to the callback, as per Laruence's earlier
  RFC
 bc break..(change the callback's signature)
 
  And give a few links to historical discussions in the same sort of area?
  E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback
 and
  its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq).
 
 thanks


In case my earlier message wasn't clear, I was asking for the RFC itself to
be padded out with those sorts of details. The reason being, many (most)
people won't be already familiar with the surrounding discussions that have
happened previously, or the reasons for the potentially strange-seeming
design choices made in this RFC.


 
 
 
  Any objections?
 
 
  —
  Best,
  Wei Dai
 
 



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/

Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices

[Peter Cowburn]

On 15 March 2015 at 15:46, Nikita Popov nikita@gmail.com wrote:

 Hi internals!

 To ensure we have no shortage of new RFC votes...

 https://wiki.php.net/rfc/reclassify_e_strict#vote

 Voting is open for ten days :)


Nikita, don't forget to start a new thread with the tag [VOTE] in the
subject line as per normal procedure. Thanks in advance.



 Thanks,
 Nikita

Re: [PHP-DEV] Reviving scalar type hints

[Peter Cowburn]

On 16 February 2015 at 16:42, François Laupretre franc...@php.net wrote:

 Hi,
 
  De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
 
  The 0.1 RFC version was mentioned a lot as a good compromise by many
  people
  and had major support.
  Maybe someone competent could pick it up, make necessary adjustments
  that
  where required and let people vote on it? Start with small steps - get
 the
  weak type hints into the language first, see how it gets used and then we
  can always add strict type hints if there is a need/desire to do that.
 
  That way we finally get type hints into the language, and those wanting
 the
  strict variety have all the opportunities in the world to add them at a
  later release with proper discussion and development time.

 That's what I am planning. If I write an RFC, it will be based on Andrea's
 0.1/0.2 version, and won't propose different modes.

 The problem is that the previous controversial RFC focused people on weak
 vs strict typing, while we should have explored other technical concerns.
 Here are the main ones I see :

 - the fact that the RFC supports single types only, like the previous
 'return type' RFC. While it is easier to implement, it opens several issues
 as multiply-typed arguments are an integral part of the PHP language
 (mostly completeness and compatibility with internal function hinting). If
 we want to support multiple types the same way for internal and userspace
 functions, we must extend the ZPP layer to support it.

 - the mechanism to check for type hints on internal functions, while easy
 to implement, is not sufficient, as a lot of internal functions get a bare
 zval from the parsing system and then convert it by themselves. With the
 proposed mechanism, there's no possible hinting on such argument, which
 will make the implementation different from the documentation. Even if the
 check is done by the function body, it won't be done in a consistent way
 with type hinting checks and won't raise a similar error. As most cases are
 related to multiply-typed args, the solution is in adding multiply-typed
 support to ZPP. Multiply-typed support needs to redefine scalar conversion
 rules, to take care of the target type being a combination of single types.

 - We need to define the appropriate extension to Reflection
 parameters/return type. That's not complex, but it takes time.

 - Other changes I'd like to propose are exposed in Bob Weinand's article,
 at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article
 explains how restricting weak conversion possibilities would make strict
 typing almost useless. Changes include forbidding bool to int/float or
 '7years' to int. This cannot be left for future additions as BC breaks will
 make it impossible. To remain consistent between userspace/internal
 functions, this must also be done at the ZPP level.

 - Using bare class names as type hints is a potential issue too, as it
 makes reserved keywords and class names share the same naming space. I
 think we should deprecate the use of class names as type hints in favor of
 'object(class-name)'. If we don't do that, every future addition of a type
 hint keyword will cause a BC break (and will be practically impossible).

 - Additional 'hybrid' types like 'numeric' and 'mixed' should be also
 provided.

 So, most features I have in mind are really 'now or never'.

 My main concern, anyway, is with March 15 announced feature freeze. If we
 need a vote by this date, it's impossible. And planning such BC for 7.1 is
 probably unrealistic because of the huge syntax additions and BC breaks it
 brings. So, if it's too late for an inclusion in 7.0, I think I'll give up.

 So, could someone confirm what 'feature freeze' exactly means ?


Note that the accepted timeline for PHP 7 [1] states that we will have
three months to Finalize implementation  testing of new features, after
the March deadline.  That should give us some time to tie down the actual
implementation side of things. Apart from that, it's more a matter of
getting an RFC drafted, discussed, voted on, before the March deadline.

I, for one, wouldn't mind the vote taking a wee while longer (say, a week
or two) if it means we can get this feature added.



 Regards

 François








  The main issues are completeness (we can give hints for some cases, but
 not for others) and, more important, the compatibility with internal
 functions. As Andrea herself agreed, her mechanism for type hinting on
 internal functions is not sufficient. Just using the ZPP macros, as they
 exist today, won't work as a lot of internal functions get a bare zval and
 then convert it by themselves. So, in this case, we would check nothing.
 So, an argument described as 'string|array' in the documentation, wouldn't
 produce the same sort of error when sent an object, than its friend,
 described as 'string'. This is not consistent and will open a lot of side
 effects if it is left out of the type hint layer.


 --
 

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

[Peter Cowburn]

Hi Marcio,

On 11 February 2015 at 20:50, Marcio Almada marcio.w...@gmail.com wrote:

 Hi internals!

 Since no new discussion topics appeared, the voting on the Group Use
 Declarations RFC for PHP7 is now open:

 RFC: https://wiki.php.net/rfc/group_use_declarations#votes
 Patch: https://github.com/php/php-src/pull/1005


I like the idea (reducing the repeated namespace parts), but am not too
keen on the syntax.

If I may offer a hastily thought out, and probably terrible, idea... how
about something like from prefix use ... ?

To adapt an example from the RFC:

from Symfony\Component\Console\Question use
ConfirmationQuestion,
ChoiceQuestion as Choice,
OptionQuestion,
Question;

That's my two cents. Best of luck!



 As requested I've split the vote into two slightly different syntax
 choices, so be sure to pick the right choice if you are going to vote yes.
 The voting will close in exactly 14 days counting from now.

 PS: Aknowledgements to Daniel Ackroyd for reviewing this RFC.

 Márcio Almada
 https://github.com/marcioAlmada

Re: [PHP-DEV] [RFC] Vote results for default ctors RFC

[Peter Cowburn]

On 25 January 2015 at 10:52, Paul Dragoonis dragoo...@gmail.com wrote:

 Hi Stas,

 Maybe a cool wiki feature addition is: once people vote they could
 optionally leave a comment right there on the wiki, which we could collect
 and read. Thoughts?


That's what the mailing list threads are for, right?  In the more distant
past, we did used to have individuals' comments on ideas in the wiki. If we
did want to go down that road again, (almost) everyone who can vote can
edit the wiki page to add their own thoughts right now.



 Here's my feedback for you on why i voted No.

 1) It felt a bit too magic for me, with no real gain from an internal or
 userland perspective.

 2) I don't see a flood of people coming to the mailing list complaining
 about this feature, so I'm not compelled to want it in the language.

 As always, thanks for your efforts.



 On Sun, Jan 25, 2015 at 8:07 AM, Stanislav Malyshev smalys...@gmail.com
 wrote:

  Hi!
 
  The vote for RFC https://wiki.php.net/rfc/default_ctor has been
  concluded, with the result of 27 vs. 20. Since 2/3 majority is required
  for acceptance, the RFC has been declined.
 
  I am a bit disappointed by the result, as I think it would be a good
  change, but I am much more disappointed by the fact that that 20 people
  voted against it and not even half of them - I would say maybe 1/5 of
  them - chose to participate in discussion even minimally and explain
  what is wrong with it in their opinion. I understand when everybody
  agrees there's no need of the flood of +1s, vote is enough, but
  disagreement by its nature is more diverse. I think not bothering to
  discuss and then just voting no with no explanation is not how the
  healthy RFC process should be working.
 
  --
  Stas Malyshev
  smalys...@gmail.com
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

Re: [PHP-DEV] [RFC] Vote results for default ctors RFC

[Peter Cowburn]

On 25 January 2015 at 15:44, Dan Ackroyd dan...@basereality.com wrote:

 On 25 January 2015 at 11:26, Peter Cowburn petercowb...@gmail.com wrote:
  That's what the mailing list threads are for, right?


 If someone has already said a reason on the list for why an RFC should
 be voted no, when someone else agrees with that reason it's not common
 for them to email, as it could be viewed as generating noise.


Any internals discussion thread can be viewed as generating noise.  How are
readers to know whether the one post mentioning a particular for/against
reason has wider support/disapproval without people saying so in the
central discussion thread(s)?  If it were a noise or nothing decision,
I'd rather have multiple people saying +1 on a particular thought or idea
*during the discussion phase* than everyone keeping quiet for fear of being
noisy.  Of course, I'd really rather posts be slightly longer and well
thought-out than +1 too.



 Also having all the reasons why an RFC was declined in one place would
 make it easier to revisit RFCs in the future. It would allow people to
 see if RFCs were declined because people thought they were just a bad
 idea, or if there was a problem with a small detail of the RFC,
 without having to wade through email archives.


There's nothing, procedurally, preventing RFC authors from summarising the
discussion around an RFC on the RFC's wiki page; say after a vote has been
finished, or even before the voting period.



 However I think there is a strong risk of people having to give a
 reason why they voted no being abused, particularly if it is shown
 while the voting was taking place, as people could be harassed for
 choosing an 'invalid' reason to reject the RFC.


I too fear the that's a terrible reason to vote the way you did knee-jerk
reactions. Then again, I could merrily vote yes to every single RFC
without raising a whiff of suspicion or ridicule. :)



 cheers
 Dan

Re: [PHP-DEV] Class constructor behaviour

[Peter Cowburn]

On 19 January 2015 at 05:48, Stanislav Malyshev smalys...@gmail.com wrote:

 Hi!

  A constructor that fails is a hard failure (factory method failed to
  produce the expected value), and is an exceptional case that can or
 cannot
  be handled (via catch).
  It's not just a failed operation (expected to eventually fail), but
  something really went wrong, badly.

 Why it is different from any other failure? I.e. fopen(doesnotexist,
 r) produces false and it's not hard failure. But if files were
 objects, new File(doesnotexist, File::READONLY) suddenly becomes hard
 failure? How the latter is harder than the former? I would say it's
 exactly the same. If you say new File can only throw, you should also
 say fopen() should only throw. If fopen can return error value, so can
 File::open(), so can new File.


Excerpt from SplFileObject's manual page [1]:

Throws a RuntimeException if the filename cannot be opened.

[1] http://php.net/splfileobject.construct


 The difference would be if File object would be built so that new File
 should never fail, and opening would be done with $file-open() and
 not with the ctor. But most of the object APIs in PHP are not written
 this way - for these APIs, ctor failure is not something exceptional
 more than failing to open file is exceptional.

  Additionally, it makes no sense to have inconsistent behavior between
  internal classes and userland classes: it is currently impossible for a
  userland class to have the `new` operator producing an object that is not
  an instance of the class after that operator.

 That can be changed if needed. This is just a missing feature.

 --
 Stas Malyshev
 smalys...@gmail.com

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

Re: [PHP-DEV] PHP 5.4.35's ChangLog is misplaced

[Peter Cowburn]

On 3 December 2014 at 14:25, Ferenc Kovacs tyr...@gmail.com wrote:

 On Wed, Dec 3, 2014 at 2:44 PM, Lior Kaplan lio...@zend.com wrote:

  Fixed.
 
  (allow a few minutes for the change to take affect).
 
 
 Hi,

 I did not fix it, because I'm not sure it is a policy that when multiple
 php versions are released then we should order them by the version and not
 by the time of the release.


I'm not aware of it being a policy either, but for ChangeLog-5.php
(excluding the one that prompted the original email in this thread),
whenever releases are on the same date they're in descending version order
in ChangeLog-5.php.

The RMs have enough on their plates at release time: worrying about the
placement of a change log in this file shouldn't be high on their list. So
long as the change log gets added.



 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Conversion of SplFileInfo instances to boolean

[Peter Cowburn]

On 3 December 2014 at 20:35, Christoph Becker cmbecke...@gmx.de wrote:

 Hello internals,

 today I stumbled over issue #65213[1] which has been reported as a bug,
 but was changed to a feature request without any hint why the conversion
 of SplFileInfo instances to boolean throws a catchable fatal error.

 Even worse, due to optimizations in OPcache (and maybe other optimizers
 as well), this does not always happen.  Consider the following snippet:

 ?php

 $o = new SplFileObject('.');
 if (!$o) {
 } else {
 var_dump(!$o);
 }

 Without any optimization this throws the error in line 4 (the if
 clause); with OPcache the error is thrown in line 6.  Apparently that is
 caused by a optimization where BOOL_NOT,JMPZ is converted to NOP,JMPNZ[2].

 IOW: with OPcache enabled `if (!$o)` works fine, but without OPcache it
 is an error.  IMHO both should behave identically.

 [1] https://bugs.php.net/bug.php?id=65213


This looks fixed in master (https://github.com/php/php-src/commit/8904f72
https://github.com/php/php-src/commit/8904f72d7c47253345f7039afd8ca754442c7e34
).


 [2] 
 http://lxr.php.net/xref/PHP_5_5/ext/opcache/Optimizer/block_pass.c#816

 --
 Christoph M. Becker

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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[Peter Cowburn]

On 30 October 2014 21:57, John Bafford jbaff...@zort.net wrote:

 Hi,

 I would like to propose the creation of a team to triage the pull requests
 on GitHub, to help ensure that the pull requests are handled in a timely
 manner. I am also volunteering to lead such a team, should the RFC be
 approved.


Slightly off-topic, but how about the same thing for bugs.php.net and
patches?



 https://wiki.php.net/rfc/github-pr

 PHP’s GitHub repository has over 180 open pull requests. Many of these are
 bug fixes or new tests that should be incorporated into PHP, but have not
 been because the PRs aren’t being regularly monitored. As a result, the
 large number of open pull requests may also be discouraging contributions,
 as potential contributors may see that pull requests are not being acted on
 and decline to submit changes.

 Thanks,

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

Re: [PHP-DEV] [PR] DateTime RFC7231 constant

[Peter Cowburn]

On 30 October 2014 11:26, Andrea Faulds a...@ajf.me wrote:


  On 30 Oct 2014, at 07:03, Trevor Suarez ric...@gmail.com wrote:
 
  Good early morning (late night for me) internals!
 
  I would like to propose a small addition be made to the DateTime date
  format constant definitions.
 
  https://github.com/php/php-src/pull/882

 Looks simple and unobjectionable. :)

  This is my first contribution to PHP's core. I wasn't sure if something
 of
  this nature would require an RFC, but I tried to register for a Wiki
  account and was met with page errors anyway (if anyone could point me in
  the right direction to notify someone of the wiki registration page
 failing
  https://wiki.php.net/rfc?do=register, that'd be awesome).

 Ah, well, for small additions like constants, an RFC is rarely necessary
 unless it’s controversial. Though there’s no harm in making one. Usually,
 if you just make a pull request for it and badger enough people, it’ll be
 merged eventually.

 The reason registration on the wiki no longer works is probably to stop
 the situation we had before, where there were git (php.net) accounts and
 wiki accounts, and the former took precedence over the latter. If you want
 to edit the wiki now, you’ll probably need a php.net account. Then just
 ask someone for karma in the /rfc/ namespace on the wiki so you can create
 and edit RFCs. I might be wrong about it being disabled intentionally,
 though.


The most common cause of errors is providing an incorrect answer to the
Which email address do you have to mail now? question  (the answer is
php-webmas...@lists.php.net).

Registration still works, at the time of writing this. After registering,
and following instructions to mail the webmaster list for rfc karma, you'll
be able to add/edit RFC pages.

Having a php.net VCS account is *not* a requirement at all. Those lucky
enough to have a php.net account do not need to ask for wiki editing karma,
everyone is able to write to all pages.



 --
 Andrea Faulds
 http://ajf.me/





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

Re: [PHP-DEV] Currently supported versions of PHP

[Peter Cowburn]

Hi Sebastian,

On 27 October 2014 09:38, Sebastian Bergmann sebast...@php.net wrote:

  Hi!

  Do we have a page that lists the versions of PHP that are currently
  supported and when their support expires?


The closest we have, at the moment, is probably http://php.net/eol.php
which details the versions which are no longer supported.


 If not, why not?


Good question.


  What I am looking for is basically a page that lists the information
  shown in the examples used in https://wiki.php.net/rfc/releaseprocess

  Thanks!
 Sebastian

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

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Peter Cowburn]

On Monday, 22 September 2014, Andrea Faulds a...@ajf.me wrote:


 On 21 Sep 2014, at 22:49, Peter Cowburn petercowb...@gmail.com
 javascript:; wrote:

  It is closed now.
 
  The vote is closed now, fact.  That does not prevent further (hopefully
 productive) discussion from happening, and it also doesn’t stipulate that
 the RFC must be merged.

 The RFC is merged. I suppose you could revert the changes, though it’d be
 a significant hassle.


Immediately reverting a change is a knee-jerk reaction that should not take
place.

That said, this vote was closed early, whether deliberately or not, and
merged, which goes against everything we've been aiming for with the
RFC process.



  Closing the vote at the most convenient opportunity, when it suits the
 author most, is not cool.

 I didn’t close it because the time suited me most. I made an honest
 mistake and closed it 22 or so hours early because I forgot I’d opened the
 vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after
 merging the patch. This was definitely not intentional.


If you say so. Still, the asking of individuals to remove their votes so
that the tally is in you favour is inexcusable.


 --
 Andrea Faulds
 http://ajf.me/

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Peter Cowburn]

On 22 September 2014 10:21, Pierre Joye pierre@gmail.com wrote:

 On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowb...@gmail.com
 wrote:

 
  If you say so. Still, the asking of individuals to remove their votes so
  that the tally is in you favour is inexcusable.

 did I miss something? What is this request to remove votes thing?


Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]

In summary, Andrea asked individuals, myself included, several times to
remove their “no” votes purely to cross the 2/3 majority threshold.  That,
along with their timely concerns raised both on- and off-list about who can
vote, leads me to think… “shenanigans”. [6]

What’s done is done, the RFC passed and was merged… let’s move along to
getting stuff done.




 --
 Pierre

 @pierrejoye | http://www.libgd.org


[1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597
[2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500
[3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456
[4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542
[5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711
[6] http://dictionary.reference.com/browse/shenanigans

Re: [PHP-DEV] Request #67949 DOMNodeList should implement ArrayAccess

[Peter Cowburn]

On 21 September 2014 12:39, Florian Margaine flor...@margaine.com wrote:

 Hi list,

 The request is so that we can do this:

 $html = HTML
 divdata/div
 HTML;
 $doc = new DOMDocument;
 $doc-loadHTML($html);
 var_dump($doc-getElementsByTagName('div')[0]-textContent);

 I started implementing this on my branch (
 https://github.com/Ralt/php-src/tree/issue-67949), but then I was
 thinking... ::offsetSet and ::offsetUnset don't really make sense in this
 context.

 From what I understand, SimpleXML does some magic to make it work without
 implementing ArrayAccess.

 I think it's cleaner to use ArrayAccess and to throw errors on ::offsetSet
 and ::offsetUnset, but I'd like internals' opinion on this.


The DOM has a very specific API that we should be keeping to, and
encouraging developers to use.

I’d *much* rather see the DOM implementation completed (check out all of
the “not implemented” parts we have), than some shiny, shiny array-style
access to NodeList items. That said, people do like the shiny, shiny.



 Regards,

 *Florian Margaine*

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

[Peter Cowburn]

On 21 September 2014 04:53, Pierre Joye pierre@gmail.com wrote:

 On Sep 21, 2014 10:48 AM, Xinchen Hui larue...@php.net wrote:
 
  On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye pierre@gmail.com
 wrote:
   Hi,
   On Sep 21, 2014 10:08 AM, Xinchen Hui larue...@php.net wrote:
  
   On Sun, Sep 21, 2014 at 11:03 AM, Andrea Faulds a...@ajf.me wrote:
   
On 21 Sep 2014, at 03:52, Xinchen Hui larue...@php.net wrote:
   
Hey:
   
it should be closed tomorrow, not today.
   
It's the 21st in my timezone. I started the vote at 2am on the 14th
 and
it's now 4am on the 21st. I don't see a problem.
  
   the problem is, you only get 16:8 on today.  and it's weekend.
  
   that means your RFC is not very common acceptable. (I have strong
   objection on it).
  
   and it's weekend,  so,  it's better to wait one day more..
  
   anyway, I see you already commit your patch... which is not very good.
  
  
   I did not manage to vote while being on the road. But I am +1. So
 consider
   it as, theoretically, 17:8.
  why you didn't?
 
  there are lot's of people didn't vote. so how to count theirs vote?
 
  (please if you have opinion.. then vote)

 It is closed now.


The vote is closed now, fact.  That does not prevent further (hopefully
productive) discussion from happening, and it also doesn’t stipulate that
the RFC must be merged.

Closing the vote at the most convenient opportunity, when it suits the
author most, is not cool. Andrea has been pushing for a while to scrape
enough votes together to get this through, as a “prerequisite for the
bigint RFC–which apparently would include these changes anyway, regardless
of the outcome of this vote– even asking “no” voters on multiple occasions
to rescind their votes.  So. Not. Cool.



  
   However the nitpicking about votes periods, % and co is getting
 annoying. I
   will see if we can clarify that. To use all possible ways to block or
 push
   RFCs is getting counter productive and produce a bad experience.
 
  and nervemind.   I respect the RFC process, even I don't like this RFC

 :-)

  thanks
  
   Cheers,
   Pierre
 
 
 
  --
  Xinchen Hui
  @Laruence
  http://www.laruence.com/

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Peter Cowburn]

On 20 September 2014 15:49, Leigh lei...@gmail.com wrote:

 On 20 September 2014 15:37, Johannes Schlüter johan...@schlueters.de
 wrote:
 
  It is unclear what a no means. Might be a related to the patch the
  design, a misunderstanding or due to a critical issue ...  in the end a
  vote creates losers with little feedback.
 
  But well, I'm saying this from day one of the voting.
 
  johannes
 

 This is my opinion exactly

 Some people who vote no are involved in the internals discussion, and
 that's great. But some people vote no without a word. How do we know
 they even understand the impact of their vote? Without their feedback
 how can the proposal be improved?

 Even if they say I'm voting no because of all of the reasons stated
 by Person X, that's enough to know that more than one person doesn't
 like a specific aspect, and makes it a higher priority for
 improvement.


This is exactly the case for the “Yes” voters too.  I’d be for having some
avenue (um... internals, or… is that the perfect place?) for giving two
cents [voluntarily] about a voter’s decision or indeed lack thereof.
Ideally, the atmosphere would be open *and inviting* (the latter appears to
be a problem here) where a pitchfork-weilding mob won’t descend on anyone
who happened to make a vote, one way or the other.

In the past we’ve had people editing wiki articles (not RFCs) with their
own thoughts as attributed annotations.  This has obvious issues, but it
would be a) in writing, and b) directly associated with the RFC, and c)
*not* a conversation.


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

Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single switch statement

[Peter Cowburn]

On 13 August 2014 10:56, Andrea Faulds a...@ajf.me wrote:


 On 13 Aug 2014, at 10:52, Pierre Joye pierre@gmail.com wrote:

  On Wed, Aug 13, 2014 at 11:42 AM, Andrea Faulds a...@ajf.me wrote:
 
  I could see
  where people would use it - there are reasons to, even if they are
 poor in
  choice to do so.
 
  How, exactly, could there ever be a use for having multiple default:
 sections and ignoring all but one? This “feature” is completely and utterly
 useless, and I’ll eat my hat if anyone intentionally relied on it.
 
  The question is more about how and when do we fix issues found while
  working on the specs? That one is pretty easy and the impact for users
  will be rather small, if at all.
 
  However, I tend to think that we should simply target php7 for any of
  these fixes. No need of endless arguing and keeps everyone happy.

 I’d rather we fix these in 5.7, which I’m a proponent of and would come
 out sooner. This way we don’t have nonsenses like this specified for three
 years.


Since the spec is targeting 5.6 [citation needed], this behaviour will need
to be in there regardless of in what version it gets fixed.


 --
 Andrea Faulds
 http://ajf.me/



My thoughts on the topic? I think we're in danger of letting process get
in our way here. It's a bug fix which IMHO should even be thrown into 5.6
 (this is a bug fix!). Going through the RFC process, being forced to wait
for 5.7 or 7, extended discussions on the list... it all just seems
unnecessary. But, that's just the opinion of a docs guy. :-)






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

Re: [PHP-DEV] PHP namespace?

[Peter Cowburn]

On 28 July 2014 09:22, Ferenc Kovacs tyr...@gmail.com wrote:

 On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

  Hi all,
 
  Since we have discussion for Next PHP, PHP namespace discussion would
 be
  nice
  to have.
 
  Currently, PHP module functions/classes/interfaces are using global(root)
  namespace.
  If it is changed to use its own namespace, user space APIs may be changed
  flexible and user controlled manner. Thus, PHP may have
 
   - Consistent naming
   - Consistent parameter order
   - Graceful function/class/interface deprecation
  (We know what we should do for these, right?)
 
  without much compatibility issues.
 
 
  PHP namespace may be used to provide PHP(and 3rd party)
  functions/classes/interfaces/constants.
  PHP\Legacy (or whatever) may be used for legacy
  functions/classes/interfaces/constants.
 
  From PHP 5.6, userland function aliasing can be done with namespace.
  Following code overrides existing function.
 
  ?php
  use function \mb_strlen as strlen;
  var_dump(strlen('日本語'));
  ?
 
  Result:
  int(3)
 
  It's good to use prefered API, but it requires use for every function
  APIs to be overridden.
  Note: Classes/Interfaces may override by use one by one also.
 
  With PHP and PHP\Legacy namespace, user may write:
 
  ?php
  namespace PHP; // Use current PHP functions/classes/interfaces/constants
 
  // Code uses current API
  ?
 
  ?php
  namespace PHP;
  namespace PHP\Legacy; // Override with legacy PHP
  functions/classes/interfaces/constants.
 
  // Code uses legacy API
  ?
 
  For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
 
  Previous example codes became:
 
  ?php
  // Code uses current API
  ?
 
  ?php
  namespace PHP\Legacy; // Override with legacy PHP
  functions/classes/interfaces/constants.
  // Code uses legacy API
  ?
 
  Issue would be codes that assume PHP
 functions/classes/interfaces/constants
  are
  defined in global(root) namespace. (e.g. \strlen()) This could be
  workaround by allowing
  use  aliasing to global(root) namespace. (e.g. use PHP\Legacy as \;)
 In
  this case,
  current functions/classes/interfaces may stay in global(root) namespace.
  (or use PHP as \;)
 
 
  Programmers may shoot their own foot by this. This is the trade off of
  flexibility.
 
  Any thoughts and/or comments?
 
  Regards,
 
  --
  Yasuo Ohgaki
  yohg...@ohgaki.net
 

 hi,

 I think it would make sense to announce that the php namespace is reserved
 for internal use, but I don't think that we are ready for moving everything
 under namespaces.


For what it's worth, the manual already states that the php namespace is
reserved for us.[1]


 The way we currently implement namespaces can't support wildcard imports so
 the migration for project would be pretty tedious, finding and replacing
 every occurance of a global function/class or use-ing every function/class,
 etc.
 namespaces has a bit clunky way of supporting constants: define always
 assumes global ns(and the const syntax only allows scalar values so it
 isn't always an option to use const).
 moving the functions to namespaces would be also a bit weird for me, as we
 currently don't support function (and const) autoloading, so it would be a
 mixed message about whether or not do we consider functions and constants
 first-class citizens used together with the later introduced oop features.

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu


[1] http://php.net/manual/en/language.namespaces.rationale.php

Re: [PHP-DEV] On voting, including the next release name.

[Peter Cowburn]

On 25 July 2014 12:17, Bishop Bettini bis...@php.net wrote:

 I just voted on the next release name https://wiki.php.net/rfc/php6. If
 you have, too: thank you.  If you haven't, I encourage you to do so.

 The way voting works now, I happen to know which option is winning.  I
 happened to know that *before* I cast my vote.  The current results are
 posted on the RFC, and the same information percolated into emails
 encouraging folks to vote. I wonder, though, if knowing which was leading
 and who chose which side affected my vote

 I propose that a poll's results tabulation be hidden until after the poll
 closes to avoid this Bandwagon Effect
 http://en.wikipedia.org/wiki/Bandwagon_effect.  Otherwise, how do we
 know
 the vote reflects just the presented arguments instead of the arguments
 *and* the weight of popularity?


We tried this [1], and it was promptly reverted [2].



 Sincerely,
 bishop


[1] https://github.com/php/web-wiki/pull/1
[2] http://markmail.org/thread/3tk3ayjy54mviuig

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP

[Peter Cowburn]

On 20 July 2014 00:26, Andrea Faulds a...@ajf.me wrote:

 Good evening,

 It is finally time to settle this matter once and for all. What shall be
 the name of the next release of PHP: PHP 6 or PHP 7?


It might be just me, but the whole RFC actually seems particularly
one-sided. The argument for PHP 6 is very short and reads half-baked.  The
overwhelming majority of this very short section of the RFC is spent
describing how naming the release “PHP 6” will be a problem, with a very
wishy-washy conclusion that the author “expects” and “thinks” it won’t end
up being a problem. The PHP 6 section makes no attempt to provide counter
points to things mentioned in the following section, nor really attempts to
make *any* strong point at all.

As for the PHP 7 section, this is by far the dominant part of the RFC. Both
in terms of physical presence, but also points and counter-points.

It also contains, IMO unnecessarily, light-hearted and jokey comments not
befitting an RFC  — unless you see the RFC as a joke too ;) — about 6 being
a failed version in other software, and 7 a lucky number. Seriously?..

The RFC as a whole is very light on trying to summarise, or at least
provide reference to, the history of PHP 6” and discussions around it.
This is disappointing, if the aim was to see a balanced summary of previous
discussions.  However, this particular gripe is a common issue with our
RFCs as a whole.

Personally, regardless of the content of the RFC, I feel that the choice is
obvious. I’m just a little concerned about the lack of quality from both
“sides” in presenting their argument(s), or not.



 The poll is now open: https://wiki.php.net/rfc/php6#vote

 Voting shall end in a week’s time on 2014-07-27.

 Thanks!
 --
 Andrea Faulds
 http://ajf.me/





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

Re: [PHP-DEV] [VOTE] RFC: Catchable call to a member function of a non-object

[Peter Cowburn]

On 29 June 2014 11:40, Timm Friebe p...@thekid.de wrote:

 Dear all,

 a couple of weeks ago, I proposed a change to the handling of the situation
 where methods are called on non-objects. Instead of an E_ERROR, the engine
 would
 raise an E_RECOVERABLE_ERROR, and enable framework and library authors to
 handle
 this.

 An intriguing usecase from my POV is to make use of this in tools like
 PHPUnit;
 instead of just printing a fatal error in the middle of a test run and
 exiting,
 the tools can decide to raise an exception and display the very much more
 helpful backtrace. No third-party PHP extensions needed for this, just a
 simple
 set_error_handler() call [1].

 I've verified various places like phpdbg and added a bunch of tests and am
 glad
 to extend that should anyone come up with a situation he/she feel this
 would
 behave in an unstable manner; athough this is realized in a somewhat
 similar
 manner to type hint mismatches, which have proven to be quite stable.

 Anyhow, I'd now like to see where we'd come out at and would kindly ask
 you to
 vote for or against inclusion of this feature:

 https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote


Any plans to close the voting, Timm?




 Thanks in advance!

 -Timm

 1:

 https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#exampleexceptions

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

Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string length and integer

[Peter Cowburn]

On 21 May 2014 07:24, Pierre Joye pierre@gmail.com wrote:

 On Tue, May 20, 2014 at 8:34 PM, David Soria Parra d...@php.net wrote:

  Sounds very good and 0.8% overhead is fine. Can we work on getting this
  integrated into a v2 of the RFC, continue hopefully constructive
 discussions for
  a week or two and then vote again. We aren't in a rush at the moment as
  php.next is far away.

 That sounds like a good reason to restart, the ML issues are good
 reasons to begin it again (sigh). However I am not even sure the
 issues are fixed by now... No activity on systems lately.


This RFC is still listed as “in voting” on the wiki.  What is its current
state?



 --
 Pierre

 @pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] not_null function

[Peter Cowburn]

On 4 July 2014 08:43, Kris Craig kris.cr...@gmail.com wrote:

 On Fri, Jul 4, 2014 at 12:26 AM, Stas Malyshev smalys...@sugarcrm.com
 wrote:

  Hi!
 
   Not any that I'm aware of, and I personally have never used is_null().
   I share your opinion that we don't really need is_null(), but with BC
   in mind, I don't think it would get removed.
 
  There's nothing to remove. Every type has is_* function, including null
  type. If is_null() is offensive to somebody for some reason, that person
  is free to not use it.
 

 I'm not offended by it and I get that it was initially created for the sake
 of having an is_* function for each type.  I'm just trying to understand
 why it's *still* there and why it's not a language construct.  It serves no
 unique purpose and has a negative performance impact.

 What would be wrong with changing it from a function to a language
 construct like isset() and empty()?  If is_null() were the equivalent of
 !isset( $var ) || $var === NULL, it would make a hell of a lot more sense
 than what's there now.


I don't use it often, and there are certainly other ways to achieve the
same result, but I have been known to employ the function as a callback
(e.g. to array_filter()) on occasion.  I'm not saying there's solid reason
to keep it around, just giving one example of a) where I've made use of it
before, and b) where changing it to a language construct would be
counter-productive.

Can we move on to frying bigger fish?!


 --Kris

Re: [PHP-DEV] Vote: Anonymous Classes

[Peter Cowburn]

On 7 October 2013 11:13, Joe Watkins krak...@php.net wrote:

 Morning Chaps,

 On the advice of many, I have restarted the vote, sorry for the
 inconvenience/confusion ...


https://wiki.php.net/rfc/anonymous_classes#voting (re-link, for the lazy)

The voting options changed from choosing a version (5.6, 5.7) or
rejecting… too a much simpler, yes/no for sticking this into master.  Which
branch/release the feature makes it into is something to be decided down
the line (ultimately, by the RMs).



 Cheers
 Joe

Re: [PHP-DEV] [VOTE] Importing namespaced functions

[Peter Cowburn]

On 15 August 2013 15:08, Igor Wiedler i...@wiedler.ch wrote:

 Hello internals,

 About 3 weeks have passed since I announced the use_function RFC. A number
 of issues were raised, and I believe all of them have been resolved at this
 point. I would like to initiate the voting phase.

 RFC: https://wiki.php.net/rfc/use_function
 Patch: https://github.com/php/php-src/pull/388

 * The vote is on the implementation, so please check the patch.
 * Since this is changing the language, it will need a 2/3 majority to be
 accepted.
 * The voting period ends in 2 weeks: on August 29th at 14.00 GMT.


Don't forget to create a new [VOTE] thread (unless you already have, and my
inbox is just being slow today).


 Cheers,

 Igor


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

Re: [PHP-DEV] [VOTE] Importing namespaced functions

[Peter Cowburn]

On 15 August 2013 15:23, Igor Wiedler i...@wiedler.ch wrote:

 Hi Peter,

 This *is* the [VOTE] thread. Am I missing something? :)


The vote is announced on the mailing list in a separate thread by sending
an email with the subject *[VOTE]*. It should reference the RFCs being
voted on and if there are different options discussed, explain these
options. It should also contain the URL of the page where the vote is
taking place.

- From  https://wiki.php.net/rfc/voting


 Regards,

 Igor

 On Aug 15, 2013, at 4:20 PM, Peter Cowburn petercowb...@gmail.com wrote:

  Don't forget to create a new [VOTE] thread (unless you already have, and
 my inbox is just being slow today).

Re: [PHP-DEV] [VOTE] Importing namespaced functions

[Peter Cowburn]

On 15 August 2013 15:23, Igor Wiedler i...@wiedler.ch wrote:

 Hi Peter,

 This *is* the [VOTE] thread. Am I missing something? :)


Stupid Gmail! :)



 Regards,

 Igor

 On Aug 15, 2013, at 4:20 PM, Peter Cowburn petercowb...@gmail.com wrote:

  Don't forget to create a new [VOTE] thread (unless you already have, and
 my inbox is just being slow today).

Re: [PHP-DEV] VCS Account Request: requinix

[Peter Cowburn]

On 8 August 2013 05:35, Hannes Magnusson hannes.magnus...@gmail.com wrote:

 \o/

 I've approved your request, which means you have full karma on
 bugs.php.net and wiki.php.net.


Good to have you on board, Damian. :)

Re: [PHP-DEV] Language constructs and callability

[Peter Cowburn]

On 19 July 2013 17:36, Daniel Lowrey rdlow...@gmail.com wrote:

 I have a simple question about the callability of language constructs and
 whether or not that's something that might change in the future. Consider:

 var_dump(is_callable('echo')); // bool(false)
 var_dump(call_user_func('echo', 'foo')); // E_WARNING
 echo('foo'); // foo

 var_dump(is_callable('isset')); // bool(false)
 var_dump(isset(1)); // E_ERROR

 Obviously this behavior arises because tokens like `echo` and `isset` are
 language constructs and not functions. I can see some potential benefits
 for working around this. For example, say I want to filter only the NULL
 elements from an array but keep the other falsy values. Recognizing
 `isset` as callable would allow me to do this:

 var_dump(array_filter([0, FALSE, NULL], 'isset')); // [0, FALSE]


array_filter([…], 'is_null');



 Of course, this limitation is trivial to work around with a userland
 callback to check for the explicit NULL equivalency, but it would be nice
 to avoid the hassle. So my question is ...

 How deeply ingrained into the engine is this behavior? Is there any chance
 of language constructs ever passing the tests for callability or is that
 just a pipe dream that's not worth the implementation effort?

Re: [PHP-DEV] Language constructs and callability

[Peter Cowburn]

On 19 July 2013 18:11, Jelle Zijlstra jelle.zijls...@gmail.com wrote:




 2013/7/19 Peter Cowburn petercowb...@gmail.com

 On 19 July 2013 17:36, Daniel Lowrey rdlow...@gmail.com wrote:

  I have a simple question about the callability of language constructs
 and
  whether or not that's something that might change in the future.
 Consider:
 
  var_dump(is_callable('echo')); // bool(false)
  var_dump(call_user_func('echo', 'foo')); // E_WARNING
  echo('foo'); // foo
 
  var_dump(is_callable('isset')); // bool(false)
  var_dump(isset(1)); // E_ERROR
 
  Obviously this behavior arises because tokens like `echo` and `isset`
 are
  language constructs and not functions. I can see some potential benefits
  for working around this. For example, say I want to filter only the NULL
  elements from an array but keep the other falsy values. Recognizing
  `isset` as callable would allow me to do this:
 
  var_dump(array_filter([0, FALSE, NULL], 'isset')); // [0, FALSE]
 

 array_filter([…], 'is_null');

 That would do the opposite of what you want.


Absolutely (I blame Friday). Still, this is only being suggested because
isset just happens to do what is needed in this case? Where to other
language constructs fit into it?



 
  Of course, this limitation is trivial to work around with a userland
  callback to check for the explicit NULL equivalency, but it would be
 nice
  to avoid the hassle. So my question is ...
 
  How deeply ingrained into the engine is this behavior? Is there any
 chance
  of language constructs ever passing the tests for callability or is that
  just a pipe dream that's not worth the implementation effort?
 

Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]

[Peter Cowburn]

On 18 June 2013 18:24, Sherif Ramadan theanomaly...@gmail.com wrote:

  Nevertheless, I'd say go with a new array_filter_key() function, because
  that permits using existing one-parameter functions like that strlen as a
  callback, instead of forcing two-parameter callback functions.
 
 The current patch does not force the callback to take two arguments. By
 default the existing behavior is maintained since the third argument is
 false by default. I still don't hear a good argument for adding a new
 function.


I'm very much on the new function side of the fence. Basic (one-word)
arguments for this include familiarity and simplicity. Familiarity, since
we're used to *_key functions for arrays. It will come as absolutely no
surprise to see the _key function spring up out of nowhere and its use is
blindingly obvious for anyone who has ever used array_filter(). Simplicity
since, err.. what were those flags again? is it $key first or $value? is
there an ARRAY_FILTER_BOTH? Also, I don't pretend my time with PHP covers
everything that everyone has ever done or wanted to do, but I cannot think
of a time when I wanted to filter an array on both the key *and* the value
at the same time: of course, it's easy to make up use cases.

Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]

[Peter Cowburn]

On 18 June 2013 23:21, Sherif Ramadan theanomaly...@gmail.com wrote:

 Are you saying that it's better to have familiarity over functionality?

 I'm not sure I agree with this premise of we shouldn't provide
 better functionality just because it would make all the other poorly
 written functions look bad. That's setting a lower bar of standards, isn't
 it?



In this case, I have a strong doubt that the better functionality will be
used, nor that it is indeed better at all. I also much prefer,
aesthetically, the _key() API over appending a flags parameter: though that
is likely, largely due to the familiarity mentioned earlier. Quite frankly
the simpler, more familiar approach looks best to me.

Also, please don't put words into my mouth: nowhere did I say, we
shouldn't provide better functionality **just because it would make all the
other poorly written functions look bad** (emphasis mine).

I appreciate you having an alternative viewpoint, but try not to see what
isn't there. What I *was* saying is that the other functions are there,
they do a great job and have been for a long time. Why not make use of that
array-function-muscle-memory; put it to our advantage?

To swing over to the other side of the fence, I do see that the flags-based
approach would work just as well in terms of getting the functionality
out there.  It is something I have thought about adding previously for a
number of other functions. The closest being adding PREG_GREP_KEY to
preg_grep(), which already has (only) PREG_GREP_INVERT. For that function,
a new flag would be the best option. For array_filter(), I'm not convinced
at all.

Re: [PHP-DEV] Callable typehint

[Peter Cowburn]

On 28 May 2013 07:00, Ferenc Kovacs tyr...@gmail.com wrote:


 snip
 sorry for resurrecting the thread, but I think that having a Callable
 typehint would be nice, and I agree with Etienne that the generic arguments
 against typehints doesn't really apply here.


We've had callable since 5.4.0.



 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

[Peter Cowburn]

On 27 May 2013 09:35, Jannik Zschiesche he...@apfelbox.net wrote:

 Hello,


 would it be hard to just show the notice as soon as the user actually uses
 a function regarding to date/time (and not before)?

 Currently the message is shown all the time, at the start of the script -
 even if the script is as simple as

 ?php

 echo 1;


 Wouldn't it be more useful if the notice only appears, if I actually use a
 date/time-function?


You're describing the current behaviour; unless I'm missing something
obvious, the warning is only displayed when you try to do something
date-related.  Your example script should not be presenting any warnings,
regardless of the date.timezone INI setting or lack thereof.




 --
 Cheers
 Jannik

Re: [PHP-DEV] [VOTE] Class instances counter

[Peter Cowburn]

On 30 April 2013 12:17, Pierre Joye pierre@gmail.com wrote:

 hi!

 Did I miss the discussions about this feature?


It was easy to miss, but a *very minimal* discussion happened towards the
beginning of April.

See [RFC] Class instances counter --
http://markmail.org/thread/o6vsxx6yj4ezh5f6




 Cheers,

 On Tue, Apr 30, 2013 at 10:04 AM, Frank Liepert frank.liep...@gmx.de
 wrote:
  See https://wiki.php.net/rfc/instance_counter#vote
 
  Voting starts as of now and ends on 7th May, 2013.
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 



 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] [VOTE] array_column() function

[Peter Cowburn]

Hi Ben,

On 28 February 2013 01:56, Ben Ramsey ram...@php.net wrote:
 Sorry. I got sick for a few weeks, and this fell to the bottom of my
 priorities list.

 I'm not sure what the next steps are. This was approved by a majority vote.
 What do I need to do now to get it into 5.5?

 Thanks,
 Ben


The next step is to get someone (anyone with php-src karma) to merge
your pull request. Assuming you're all done and happy with the pull
request?

The RMs (cc'd) are looking to tag the beta tomorrow and I for one
would like to get this little function in there.

Cheers,
Peter

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