Re: [PHP-DEV] Re: [RFC] Namespace syntax decision

that emotion. I'm aware that there's already been a lot of discussion on this already, but as one who's already begun programming prototype code with namespaces, I agree with Johannes and Sebastian here. +1 -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] Return type hints

that regular function declarations would be like: Itest function testing($instance) { return $instance; } Would this present a problem? -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: my last attempt at sanity with namespaces

reason to remove namespaces? +1 for #3 -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] Addition of setcookie2() to support RFC 2965

.) -- Ben Ramsey http://benramsey.com/ Index: ext/standard/basic_functions.c === RCS file: /repository/php-src/ext/standard/basic_functions.c,v retrieving revision 1.725.2.31.2.53 diff -u -w -r1.725.2.31.2.53 basic_functions.c --- ext

Re: [PHP-DEV] [PATCH] Addition of setcookie2() to support RFC 2965

that you may not use all of them. Maybe it's better to have them as an array of secondary parameters? Yep. Sara already suggested this to me, so I'm working on a new patch for this. Thanks! -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List

[PHP-DEV] [PATCH] Generate warning when using PDO::setAttribute() and ATTR_PERSISTENT

() raised a warning if you try to set PDO::ATTR_PERSISTENT, by the way. I'm submitting the attached patch to do just that. :-) -- Ben Ramsey http://benramsey.com/ Index: ext/pdo/pdo_dbh.c === RCS file: /repository/php-src/ext/pdo

Re: [PHP-DEV] [PATCH] Generate warning when using PDO::setAttribute() and ATTR_PERSISTENT

On 10/26/07 2:44 PM, Andi Gutmans wrote: Why is it not an if() statement? It can be an if() statement. I added it as a switch in the expectation that other attributes might be added to it in the future. -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing

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

I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting Regards, Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

On 1/12/13 9:14 AM, Peter Cowburn wrote: The Status for this RFC is still Under discussion and on the RFC listing page it is the same. Is not changing those two things simply an oversight? It was an oversight. I have corrected it in both places. -- PHP Internals - PHP Runtime Development

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

On 1/12/13 9:19 AM, Derick Rethans wrote: I'm liking this, why start with an function alias already when introducing a new feature? I figured this would be a frequent question, and I was right. :-) In earlier discussions (June 2012), when I first introduced array_column(), much of the

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

On 1/12/13 10:17 AM, Levi Morrison wrote: 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you want this to be part of 5.3? The RFC (in particular the vote question) does not make it clear where/when you want this to be added. Please, this is not a bug or security fix. It does

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

On 1/12/13 10:13 AM, Peter Cowburn wrote: 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you want this to be part of 5.3? The RFC (in particular the vote question) does not make it clear where/when you want this to be added. I mentioned this in another response on this thread.

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

On 1/11/13 6:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping

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

On 1/14/13 11:54 AM, Scott MacVicar wrote: On 14 Jan 2013, at 11:37, Ben Ramsey ram...@php.net wrote: On 1/11/13 6:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting I have updated the pull request

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

On 1/14/13 3:49 PM, Pierre Joye wrote: hi! Btw, really willing to have this function but I agree with other here, the alias must go. It makes no sense to introduce a function and an alias to it at the same time. Maybe restart the vote and let choose function name. Options: 1. array_column 2.

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

...@pcservice.co.zawrote: On 12 January 2013 00:17, Ben Ramsey ram...@php.net wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting Regards, Ben The vote has been open for almost three weeks and discussion tailed off after only

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

Please kill that alias. It is pointless to introduce a new function with an alias for it. I killed the alias in this commit: https://github.com/ramsey/php-src/commit/3439a098a0b646ff05d4da9748996214cac39d12 -Ben

[PHP-DEV] Functionality updates to array_column()

I've just submitted the following pull request for updates to the array_column() function: https://github.com/php/php-src/pull/331 I asked about these changes on the #php.pecl IRC channel a few weeks ago, and others on the channel agreed that it was best to go ahead and submit these changes

[PHP-DEV] [DRAFT] RFC - array_column() function

Hi all, I've written a draft version of an RFC for pull request 56 ( https://github.com/php/php-src/pull/56 ), to add array_column() to the core. Please take a look and provide feedback so that I can improve the patch/proposal. https://wiki.php.net/rfc/array_column Thanks, Ben -- PHP

Re: [PHP-DEV] [DRAFT] RFC - array_column() function

On 6/22/12 5:32 AM, Léo Peltier wrote: Hi, Shouldn't this be called 'array_pluck'? This is the name people usually use when implementing it in PHP (see array_pluck( vs array_column( in Google) or in other languages/libs (see underscorejs, prototypejs and RoR). I'm open to changing or

Re: [PHP-DEV] [DRAFT] RFC - array_column() function

On 6/25/12 9:44 AM, Matthew Weier O'Phinney wrote: On 2012-06-23, Stas Malyshev smalys...@sugarcrm.com wrote: I'm open to changing or aliasing the name to array_pluck(), if others are in agreement. I wouldn't know what pluck means here. Column is a clear word with established meaning. Let's

[PHP-DEV] Deadlock with session handling code?

both somewhat stuck with no clue how to proceed with this. Thanks, Ben Ramsey I'm having a major problem with my PHP scripts getting stuck on one of our production servers. The system runs normally for a while, but after some time, certain httpd processed get wedged. This causes the server

Re: [PHP-DEV] Deadlock with session handling code?

(). For the second part, here's what my co-worker sent me: /usr/include$ grep F_SETFD `find . -type f` ./asm/fcntl.h:#define F_SETFD 2 /* set/clear close_on_exec */ ./bits/fcntl.h:#define F_SETFD 2 /* Set file descriptor flags. */ -- Ben Ramsey http

Re: [PHP-DEV] Deadlock with session handling code?

0x08066c34 in ap_graceful_stop_signalled () #40 0x08066ed9 in ap_graceful_stop_signalled () #41 0x08067570 in ap_mpm_run () #42 0x0806da4f in main () (gdb) [/snip] -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net

Re: [PHP-DEV] Deadlock with session handling code?

understand it, the RedHat version of PHP they are using may have an old version number, but it contains all security patches up to the current version of PHP (though I'm unclear whether those patches include any new features, etc.). -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Re: Syntax in PHP 6

? -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] filter extension

as experimental? -- Ben Ramsey http://benramsey.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [Fwd: PHP Access Violation using PEAR::Mail_smtp]

, 05 Apr 2004 13:58:31 -0400 From: [EMAIL PROTECTED] (Ben Ramsey) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Newsgroups: php.general,php.pear.general I'm getting the following error when using the Mail_smtp package from PEAR: PHP has encountered an Access Violation at 0177A8B4 It does not occur

Re: [PHP-DEV] [Fwd: PHP Access Violation using PEAR::Mail_smtp]

a blank page with: PHP has encountered an Access Violation at 0177A9D4 Like I said, I'll try to pare down the code, but I feel out of luck here, since it's occurring intermittently. Thank you for your time. -- Regards, Ben Ramsey http://benramsey.com http://www.phpcommunity.org/wiki/People

Re: [PHP-DEV] [Fwd: PHP Access Violation using PEAR::Mail_smtp]

expressed an interest in knowing how it got resolved. -- Regards, Ben Ramsey http://benramsey.com http://www.phpcommunity.org/wiki/People/BenRamsey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [Fwd: PHP Access Violation using PEAR::Mail_smtp]

on Windows. I am running Windows Server 2003, IIS 6, with PHP 5RC1 (latest snapshot) ISAPI module. -- Regards, Ben Ramsey http://benramsey.com http://www.phpcommunity.org/wiki/People/BenRamsey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Access Violations / Corruptions / Refs to temps

, Ben Ramsey http://benramsey.com http://www.phpcommunity.org/wiki/People/BenRamsey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: ramsey

I will be using my CVS account to maintain English documentation for PHP-GTK. Steph sent me. :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Using my php.net e-mail address...

or to allow specific addresses through without the need for this authorization? -- Regards, Ben Ramsey http://benramsey.com --- http://www.phpcommunity.org/ Open Source, Open Community Visit for more information or to join the movement

Re: [PHP-DEV] Using my php.net e-mail address...

goes to the same address (the one that's listed there now). Curt Zirzow wrote: * Thus wrote Ben Ramsey: I want to use my php.net e-mail address for certain things which require authorization sent back to the e-mail address. However, this is impossible, as a human must respond to the bounceback

Re: [PHP-DEV] Configure/buildconf/autoconf errors

from a package or something? You should have a libtool.m4 file containing the AC_PROG_LIBTOOL macro in that ac-dir that aclocal knows about. So, basically, reinstall autoconf/automake/libtool correctly, and read up on aclocal. -Rasmus On Fri, 13 Aug 2004, Ben Ramsey wrote

[PHP-DEV] [Fwd: PHPGTK.NET -- want it?]

I forwarded this here because I figured it's the best place for it. This person will donate phpgtk.net to the PHP Group for free, so long as the domain name goes to the official PHP-GTK project and not to any one individual. Contact them for information regarding the transfer of name, if

Re: [PHP-DEV] PHP Language Specification

On Jul 22, 2014, at 5:41 PM, Andrea Faulds a...@ajf.me wrote: On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com wrote: The big question here, though, is whether, going forward, we'll be able to mentally switch to a spec first mentality. If not, the spec will get out of date

Re: [PHP-DEV] PHP Language Specification

On Jul 23, 2014, at 1:59 PM, Rowan Collins rowan.coll...@gmail.com wrote: On the flip side, there is definitely value in representatives from other implementations having a voice in changes that affect them, but that could just mean ensuring that members of those projects are involved within

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 7:47 AM, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:09 AM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:25 AM, Andrea Faulds a...@ajf.me wrote: Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. But they

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:30 AM, Chris Wright c...@daverandom.com wrote: I suggested this a while ago, people didn't like the idea, and I'm not sure I do any more, either. We'd do much better focusing on creating a standard native request *object* which provides clean access to this data, and

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 8:42 AM, Kris Craig kris.cr...@gmail.com wrote: Removing or renaming $_GET and $_POST would also create confusion and almost certainly cause widespread BC breakage on a pretty massive scale. And there's really no gain to offset that. So that just leaves us with either

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 9:08 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: So $_QUERY and $_FORM, then. That sounds about right. Did I just name a global variable? W00t! Anyhow, yeah neither one is technically 100%

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 14, 2014, at 9:20 AM, Park Framework park.framew...@gmail.com wrote: 2014-10-14 17:09 GMT+03:00 Mike Dugan m...@mjdugan.com: If no one else is already working on it, I can write one up this morning/early this afternoon and submit it. Ok The RFC In this topic will be included

Re: [PHP-DEV] New globals for PUT and DELETE

On Oct 26, 2014, at 4:30 PM, Will Fitch willfi...@php.net wrote: 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. I would be supportive of this, and I’ll even

Re: [PHP-DEV] PR #1325 - array_column() for array of objects

On Sat, Jun 13, 2015 at 11:46 AM, Rowan Collins rowan.coll...@gmail.com wrote: On 12 June 2015 02:31:18 BST, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi, I've created a PR here: https://github.com/php/php-src/pull/1325 This enhancement allows for properties on objects to work in

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

> On Jan 5, 2016, at 10:03 AM, Paul M. Jones <pmjone...@gmail.com> wrote: > > >> On Jan 5, 2016, at 09:55, Ben Ramsey <b...@benramsey.com> wrote: >> >> >>> On Jan 4, 2016, at 10:29 PM, Paul M. Jones <pmjone...@gmail.com> wrote: >&

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

> On Jan 4, 2016, at 10:29 PM, Paul M. Jones wrote: > > If there's an accusation, then *due process* needs to be applied. If it rises > to the level of needing *due process* then the police should be involved. > There's no need, *none at all*, for a star chamber *or* a

Re: [PHP-DEV] [RFC] [Discussion] UUID

none at all. I use default PHP built-in stuff for > > everything. Even the parameter parsing is 1:1 as it would be if you > > would define the very same class in PHP. > > > > I will extend my signature with "No Magic!" now. ;) > > > > Perfect, this abs

Re: [PHP-DEV] RFC Process: more productive conversations

> On Mar 25, 2019, at 11:56, Peter Bowyer wrote: > > On Mon, 25 Mar 2019 at 15:24, Andreas Heigl wrote: > >> Shall we then also expect people that vote "yes" to explain why they voted >> for the feature? To see whether they understood what they where voting on? >> > > Yes. > > >> Then we

Re: [PHP-DEV] [RFC] Arrow functions / short closures

> On Mar 13, 2019, at 10:56, Nikita Popov wrote: > > Hi internals, > > Motivated by the recent list comprehensions RFC, I think it's time we took > another look at short closures: > > https://wiki.php.net/rfc/arrow_functions_v2 > > This is based on a previous (withdrawn) proposal by Levi &

Re: [PHP-DEV] unload/reload classes?

> On Mar 18, 2019, at 18:45, Robert Hickman wrote: > > 1: I have seen an extension which allows functions/classes to be > redefined, although I can't remember what it is called. Maybe you’re thinking of the runkit extension? https://secure.php.net/manual/en/book.runkit.php Cheers, Ben

Re: [PHP-DEV] [RFC] Arrow functions / short closures

> On Mar 13, 2019, at 15:56, Rowan Collins wrote: > > I suggest you both read the RFC; about half the page is dedicated to > summarising the syntaxes which have been considered, and the pros and cons of > each. > > The summary of that syntax begins: > > > This is both the most popular and

Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

> On Feb 6, 2019, at 01:22, Peter Kokot wrote: > I can help sort this mess. A separate fork out of the php/php-src was > not such a good idea. Sorry. I made many poor decisions around how I managed that entire event. It’s my own personal Fyre Festival. :-( I’m happy to help in any way I can to

Re: [PHP-DEV] Make bcmath functions more strict

> On Feb 7, 2019, at 11:47, Vladyslav Startsev > wrote: > > Hello everyone! > > Recently I noticed that there are strange behavior going on if I use > bcmath functions (some examples you can see here > https://3v4l.org/D3s7J). I also previously had little discussion with > Sara Golemon on

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

> On Feb 16, 2019, at 12:28, Benjamin Eberlei wrote: > > This exception is only for argument errors. Fopen would continue to warn + > false when file doesnt exist, which is what @ is nostly used for (using fopen > as example) I’ve seen many cases where it’s understood that the function

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

> On Feb 5, 2019, at 05:22, Nikita Popov wrote: > > Hi internals, > > I'd like to bring forward the following proposal for PHP 8, which will make > (zpp) parameter parsing failures always result in a TypeError (rather than > generating a warning+null, depending on circumstances): > >

Re: [PHP-DEV] What's up with github.com/php-src?

> On Feb 8, 2019, at 22:46, Bishop Bettini wrote: > > Having mistakenly cloned php-src/php > instead of php/php-src (again), I figured > I'd ask -- is php-src used for anything? > > The code seems to be quite old, and the

Re: [PHP-DEV] What's up with github.com/php-src?

> On Feb 9, 2019, at 10:00, Leigh wrote: > > Indeed. It was meant as a joke, not to deceive anyone. I'll take it down :) FWIW, I thought it was hilarious. :-) -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net problems?

> On Feb 9, 2019, at 18:15, Stanislav Malyshev wrote: > > Hi! > > I am trying to access bugs.php.net and I am getting timeouts all the > time today (TLS handshake passes, but no content is delivered). Seems to > be something wrong with the site? Could somebody check it? I’ve been experiencing

Re: [PHP-DEV] wiki.php.net

> On Feb 14, 2019, at 02:33, Sebastian Bergmann wrote: > > Who is in charge of wiki.php.net and updates for its software? I ask because > every time I am (logged in) on that site I see warnings such as > > Hotfix release available: 2018-04-22b "Greebo". upgrade now! > Hotfix release

[PHP-DEV] Make target install-pear is failing

Earlier today, someone reported pear.php.net as being down. I checked, and it’s loading, so I sent it back to them for Feedback. Later, I built PHP with PEAR so I could use the `pecl` command to install an extension for testing. When I ran `make install`, I got a nasty failure on the

[PHP-DEV] Re: Make target install-pear is failing

> On Feb 11, 2019, at 18:04, Christoph M. Becker wrote: > > On 12.02.2019 at 00:42, Ben Ramsey wrote: > >> Earlier today, someone reported pear.php.net as being down. I checked, and >> it’s loading, so I sent it back to them for Feedback. Later, I built PHP >

[PHP-DEV] Re: Make target install-pear is failing

> On Feb 11, 2019, at 18:21, Christoph M. Becker wrote: > > You can get the installers from > . Perfect! Thanks! Cheers, Ben signature.asc Description: Message signed with OpenPGP

Re: [PHP-DEV] bugs.php.net problems?

> On Feb 11, 2019, at 00:03, Rasmus Lerdorf wrote: > > Are you still seeing this? It is a Digital Ocean VM in NYC1 and I don't see > anything odd aboout it. Are you hitting it over ipv4 or ipv6? I was on bugs.php.net a bit yesterday, and I didn’t notice it anymore. I was hitting it over

Re: [PHP-DEV] [RFC] JIT

On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote: > I'm honestly a bit perplexed by how many people here viewing Windows > support as a must have, while at the same time I think we all agree PHP is > very scarcely found on production Windows servers, and JIT is a > predominantly production

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

> On Jun 16, 2019, at 07:04, Mark Randall wrote: > > On 15/06/2019 22:53, Wes wrote: >> Hello PHP, I just published >> https://wiki.php.net/rfc/alternative-closure-use-syntax >> I would love your opinion on this > > I'm not overly fond of it myself because I think it could make it slightly >

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

> On Jun 17, 2019, at 12:50, Mark Randall wrote: > > On 17/06/2019 15:40, Ben Ramsey wrote: >>> Where "use (...)" would auto-capture all of the used variables in a similar >>> manner to short closures, that would certainly save a bit of time. >

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

> On Jun 22, 2019, at 10:32, Nikita Popov wrote: > >> On Thu, Jun 20, 2019 at 12:32 AM wrote: >> >> I sent this earlier this week without [RFC] in the subject line...since >> some people might have filters to check the subject line I wanted to >> send this again with the proper substring in

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

> On Jun 23, 2019, at 05:35, Rowan Collins wrote: > > On 22 June 2019 20:56:24 BST, Ben Ramsey wrote: >> Perhaps it would only be an issue with the case-insensitive versions, >> as Nikita points out? If so, can someone provide some example strings >> where an mb_st

Re: [PHP-DEV] Proposal for a RFC

> On May 6, 2019, at 09:37, Steven Wade wrote: > > That being said, adding an interface like `ArraySerializable` might be nice > too. I'm seeing technical arguments against adding magic casts, but (just > spit-balling here), what if a class implemented a new `ArraySerializable` > interace

Re: [PHP-DEV] Proposal for a RFC

> On May 4, 2019, at 09:58, Steven Wade wrote: > > Hi Internals team! > > I have an idea for a feature that I'd love to see in the language one day and > wanted to run the idea by you all. > > The idea is to add a new magic method "__toArray()" that would allow a > developer to specifiy

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

> On Jul 8, 2019, at 13:09, Björn Larsson wrote: > > Having this _ci postfix is a new way of indicating case insensitivity. > I think that it might add to negative votes. Personally I think it's a > good idea to mimic existing ways, even if they are a bit awkward. > > How about using a flag or

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

> On Aug 14, 2019, at 11:14, Derick Rethans wrote: > > Hi, > > In the last week(s) there has been a lot of chat about Zeev's P++ idea. > Before we end up spending this project's time and energy to explore this > idea further, I thought it'd be wise to see if there is enough animo for > this.

Re: [PHP-DEV] Silent Types

> Andreas Hennings wrote: > > In some other languages the mixed type is called "variant". > https://en.m.wikipedia.org/wiki/Variant_type > I mostly remember it from VisualBasic. Union types are probably better than specifying a variant or mixed type. At present, parameters and properties with

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

> On Aug 7, 2019, at 09:03, Peter Bowyer wrote: > > On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd wrote: > >> I think when we adopt a Code of Conduct one of the things we need to >> make explicit is that "claiming authority that is not codified" is >> explicitly a thing that will not be allowed in

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

> On Aug 7, 2019, at 09:09, Ben Ramsey wrote: > >> On Aug 7, 2019, at 09:03, Peter Bowyer wrote: >> >> On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd wrote: >> >>> I think when we adopt a Code of Conduct one of the things we need to >&g

Re: [PHP-DEV] Using PECL without installing PEAR

> On Nov 13, 2019, at 10:43, Matthieu Napoli wrote: > > Hi all, > > Following a discussion with Nikita, I understood that [installing PEAR with > PHP is > deprecated](https://github.com/php/php-src/blob/PHP-7.4/UPGRADING#L98-L101 >

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 17, 2019, at 17:28, Mike Schinkel wrote: > > If we are going to open up arrays for enhancement in PHP 8 I would ask that > we seriously consider addressing the various differences between a built-in > array and an instance of ArrayObject and/or the related associated interfaces >

Re: [PHP-DEV] SimpleXMLIterator

> On Feb 28, 2020, at 13:59, Mike Schinkel wrote: > > Well, that did not work as intended... > > >> On Feb 28, 2020, at 2:57 PM, Mike Schinkel wrote: >> >> OFFLIST The “off list” command has an underscore in it: OFF_LIST. ;-) Cheers, Ben signature.asc Description: Message signed with

Re: [PHP-DEV] OSI approval for PHP 3.01 license

> On Mar 4, 2020, at 11:59, Derick Rethans wrote: > > On Wed, 4 Mar 2020, Ben Ramsey wrote: > >>>> On Mar 4, 2020, at 11:26, Stanislav Malyshev wrote: >>> >>> Hi! >>> >>>> Does anyone here remember why the changes to the

Re: [PHP-DEV] OSI approval for PHP 3.01 license

> On Mar 4, 2020, at 11:26, Stanislav Malyshev wrote: > > Hi! > >> Does anyone here remember why the changes to the license where done in >> the first place? The commit was done on the 1st of Jan. 2006 (at least > > Probably for more clear wording (since outside of context "PHP" can mean >

Re: [PHP-DEV] OSI approval for PHP 3.01 license

> On Mar 5, 2020, at 15:28, Stanislav Malyshev wrote: > > Hi! > If this version is approved, will the steward voluntarily deprecate version 3.0, and if not, and if 3.01 is approved, should 3.0 be involuntarily deprecated? >> >> >> The “steward” is the PHP Group. I know that

Re: [PHP-DEV] OSI approval for PHP 3.01 license

> On Mar 5, 2020, at 16:31, Christoph M. Becker wrote: > > On 05.03.2020 at 22:36, Ben Ramsey wrote: > >> There is some concern at the OSI about these clauses, when the license is >> applied to any projects not owned by the PHP Group. I’ll keep everyone here >>

Re: [PHP-DEV] [RFC] [DISCUSSION] str_contains

> On Feb 23, 2020, at 03:12, Philipp Tanlak wrote: > > Hey PHP Devs! > > Since the RFC to str_contains is now almost a week old and most of the > discussion happened in the initial discussion/proposal thread, I wasn't > sure if everyone has seen it. Therefore I'd like to create this new email >

Re: [PHP-DEV] [RFC] [DISCUSSION] str_contains

> On Feb 24, 2020, at 10:52, Philipp Tanlak wrote: > >> Ben Ramsey schrieb am Mo. 24. Feb. 2020 um 17:21: >> > On Feb 23, 2020, at 03:12, Philipp Tanlak wrote: >> > >> > Hey PHP Devs! >> > >> > Since the RFC to str_contains is now a

Re: [PHP-DEV] Operator overloading for userspace objects

> Also, I want to reiterate: Any of these operations MUST be designed to return > a new value, never modify in place. These operators only make sense on value > objects, not service objects, and value objects should be immutable. I completely agree. This was the gist of my earlier comments.

Re: [PHP-DEV] Operator overloading for userspace objects

> If we still want operator overloading and we want to force operator > overloading to require immutability, I believe that means we would need an > immutability RFC to be approved (and implemented?) before operator > overloading requiring immutability could be approved. Something like this:

Re: [PHP-DEV] Operator overloading for userspace objects

> On Jan 28, 2020, at 17:14, > wrote: > > Hello everybody, > > > > the last days I have experimented a bit with operator overloading in > userspace classes (redefing the meaning of arithmetic operations like +, -, > *, etc. for your own classes). > > This could be useful for different

Re: [PHP-DEV] Operator overloading for userspace objects

> On Jan 28, 2020, at 17:55, Michael Cordover wrote: > > On Tue, Jan 28, 2020, at 18:47, Ben Ramsey wrote: >> If you take mutation off the table, then things become easier, IMO. We >> only need two magic methods: >> >> * __toInteger(): int >> *

Re: [PHP-DEV] @official_php credentials?

> On Feb 4, 2020, at 04:29, Derick Rethans wrote: > > Hi, > > Adam gave them to me last night, so: me. > > cheers, > Derick > > >> On Tue, 4 Feb 2020, Nikita Popov wrote: >> >> Hi, >> >> Does anyone know the credentials for the @official_php Twitter account? >> None of the releases

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

> On Feb 11, 2020, at 07:20, Aimeos | Norbert Sendetzky > wrote: > > Am 11.02.20 um 14:11 schrieb Michał Brzuchalski: Traversable, Serializable, Countable, Throwable, JsonSerializable all are related to some special engine behavior, which this ones also is. >>> >>> But one could

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

> On Feb 10, 2020, at 10:18, Paul M. Jones wrote: > > Hi Internals, > > After a couple of years of incubation, I am happy to offer a second version > of this RFC: > > https://wiki.php.net/rfc/request_response > > It proposes an object-oriented approach around request and response >

Re: [PHP-DEV] Who are the current eligible voters?

> On Jan 15, 2020, at 13:19, Paul M. Jones wrote: > > Hi all, > > Apropos the Nicolas Grekas discussion on this list ... > > > > ... and on Reddit ... > > > >

Re: [PHP-DEV] Who are the current eligible voters?

> On Jan 15, 2020, at 14:02, Paul M. Jones wrote: > > > >> On Jan 15, 2020, at 13:21, Ben Ramsey wrote: >> >> Everyone with a php.net account is able to vote. The public list is here: >> https://people.php.net/ > > I don't think that's *qu

Re: [PHP-DEV] Who are the current eligible voters?

> On Jan 16, 2020, at 06:47, Aleksander Machniak wrote: > > On 15.01.2020 21:15, Nikita Popov wrote: >> Yes, having a php.net account is sufficient. Additionally there are 28 >> users in the wiki in the "phpcvs" group, which I *think* means they can >> also vote. >> >> Based on master.php.net

Re: [PHP-DEV] [RFC] Static return type

> On Jan 8, 2020, at 05:42, Nikita Popov wrote: > > Hi internals, > > I would like to propose the following RFC, which allows using "static" as a > return type: > > https://wiki.php.net/rfc/static_return_type > > While I'm personally not a fan of late static binding, we do support it and >

Re: [PHP-DEV] OSI approval for PHP 3.01 license

> On Mar 10, 2020, at 23:56, Stanislav Malyshev wrote: > > Hi! > >> Bump. Anyone? >> >> If there are no objections, can someone go ahead and merge this? > > I merged it. Thanks, Stas! Cheers, Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

  1   2   3   4   >