Re: [PHP-DEV] Protected destructors

On Sep 28, 2024, at 13:23, Jonathan Vollebregt wrote: > >> Okay. My point is that you cannot know (unless there are no circular >> dependencies) *when* a destructor is called by the engine; > > The benefit of non-public visibility isn't when it's called, but how many > times it's called. If yo

Re: [PHP-DEV] Local constants

> On Sep 4, 2024, at 16:45, Rob Landers wrote: > > I think, conceptually, this makes sense, but maybe I'm the only one who writes > > $arr = doSomething(); > $arr = array_map(fn($x) => $x->prop, $arr); > $arr = array_filter($arr, $filterFunc); > > instead of > > $arr = array_filter(array_map

Re: [PHP-DEV] Local constants

On Sep 4, 2024, at 15:23, Rob Landers wrote: > > On Tue, Sep 3, 2024, at 05:20, HwapX wrote: >> Hello internals! >> >> I was wondering, has there been any discussion about supporting local >> constants (variables that cannot be reassigned, perhaps even function >> parameters)? > > Out of curi

Re: [PHP-DEV] [RFC] Default expression

> On Aug 27, 2024, at 10:14, Rowan Tommins [IMSoP] wrote: > > The only expressions that are in some sense "safe" are those that can apply > equally to any possible type that the function could in future set as the > default. In theory, that includes a match statement with an arm of "default

Re: [PHP-DEV] [RFC] Default expression

On Aug 25, 2024, at 14:46, Rowan Tommins [IMSoP] wrote: > > On 25/08/2024 18:44, John Bafford wrote: > >> Although I'm not sold on the idea of using default as part of an >> expression, I would argue that a default function parameter value is >> fair game to be

Re: [PHP-DEV] [RFC] Default expression

Hi Rowan, > On Aug 25, 2024, at 11:31, Rowan Tommins [IMSoP] wrote: > > 3) The expression should be passing additional information into the function, > not pulling information out of it. The syntax shouldn't be a way to write > obfuscated reflection, or invert data flow from callee to caller.

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Aug 16, 2024, at 10:17, Larry Garfield wrote: > > I would have to research to see if other languages did this, but one option > would be to allow an inner class to extend an outer class even if it's final, > which would essentially give us sealed classes for free: > > final class Outer > {

Re: [PHP-DEV] [Early Feedback] Pattern matching

> On Jun 21, 2024, at 11:42, Niels Dossche wrote: > > On 21/06/2024 14:43, Robert Landers wrote: >> On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings wrote: >>> >>> E.g. should something like array be added to the type system in >>> the future, or do we leave the type system behind, and rely

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

Hi Benoît, > On Jun 7, 2024, at 12:03, Benoît Condaminet > wrote: > > As a first try, I start updated code to completely make the new keyword > optional, like in Dart language for example, but it require very big change, > with lot of impact (collision with function). > > So here is my prop

Re: [PHP-DEV] [VOTE] Interface Default Methods

On Jul 11, 2023, at 13:42, Larry Garfield wrote: > > On Tue, Jul 11, 2023, at 5:28 PM, Robert Landers wrote: >> >> IMHO, using a shared base class reflects the inheritance better >> because they are siblings (at least these appear to be logical >> siblings out of context, IMHO) and should look l

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

Hi everyone, Apologies for not including context and responding to 40 emails all at once, I’m not at a computer (and won’t be for a few weeks). Given the comments I read in the thread, I wanted to make some key points that I hope will clarify my intent behind the proposal: * The primary motiva

Re: [PHP-DEV] Request for couple memory optimized array improvements

Hi Riikka, > On Aug 31, 2020, at 14:13, Riikka Kalliomäki > wrote: > > A common pattern that I've seen that could dearly use PHP internal > optimization, if possible, would be: > > foreach (array_keys($array) as $key) { > } I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch

Re: [PHP-DEV] [RFC] Guard statement

Pavel, On May 16, 2020, at 05:13, Pavel Patapau wrote: > > Hello everyone, > > I want to propose new syntax addition - guard statement, that executes code > only if expression equals false and must contain control-flow changing code, > and written a respective RFC: > > https://wiki.php.net/r

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

Benas, > On May 15, 2020, at 04:33, Benas IML wrote: > > Hey, > > `guard` would be a keyword this means that all of the classes, interfaces and > traits named Guard would be illegal. Therefore Laravel's `Guard` interface > would be incompatible with PHP 8 which in turn means thousands of web

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

Benas, > On May 10, 2020, at 15:19, Benas IML wrote: > > Hello, > > I think that we SHOULD not introduce a new keyword (e. g. guard) since that > would be a "major major" backwards incompatibility. "Guard" is a really > generic > word and a great example of that is Laravel and their authentic

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

Hi Ralph, > On May 10, 2020, at 11:49, Ralph Schindler wrote: > > Hi! > > > # Intro > > I am proposing what is a near completely syntactical addition (only change is > to language.y) to the language. The best terminology for this syntax is are: > `return if`, "return early", or "guard claus

Re: [PHP-DEV] [RFC] Named arguments

Hi Rowan, > On May 5, 2020, at 16:47, Rowan Tommins wrote: > > Hi John, > > On 05/05/2020 18:27, John Bafford wrote: >> I very much do like the idea of named parameters, but I do not like the >> specific proposal in the linked RFC at all. I think that treating nam

Re: [PHP-DEV] [RFC] Named arguments

On May 5, 2020, at 14:21, Nikita Popov wrote: > > Another is to allow specifying the public parameter name and the private > parameter variable name separately, as is possible in Swift. This would > allow changing "parameter" names arbitrarily, without breaking the public > API. This would be a p

Re: [PHP-DEV] [RFC] Named arguments

Hi Nikita, > On May 5, 2020, at 09:51, Nikita Popov wrote: > > Hi internals, > > I've recently started a thread on resurrecting the named arguments proposal > (https://externals.io/message/109549), as this has come up tangentially in > some recent discussions around attributes and around object

Re: [PHP-DEV] Typed array properties V2

> On Jan 24, 2020, at 14:27, Mike Schinkel wrote: > > Thus far we have discussed that implementation of type checking for arrays > would be too costly from a performance perspective and that there is no good > solution that is not extremely complicated to implement. > > Given that, can we co

Re: [PHP-DEV] Typed array properties V2

> On Jan 19, 2020, at 19:53, Mike Schinkel wrote: > > P.S. There was also the mention by Levi Morrison that the type[] syntax was > a poor one because of ambiguity between (?int)[] or ?(int[]). I would argue > that the latter would likely occur orders of magnitude more often than the > fo

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

Chase, On Jan 22, 2016, at 13:15, Chase Peeler wrote: > > 1.) I think everyone already knows how to be an adult. The fact that > sometimes we don't act in a civil manner isn't because we don't have > something telling us what civil behavior entails. Putting it in writing > might make us feel goo

Re: [PHP-DEV] Back to the code (was Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct))

Adam, Sascha, > On Jan 13, 2016, at 08:53, Adam Howard wrote: > > Well, I'm glad someone is in agreement. I really wish we'd get back to the > actual code. Because if not, I do think perhaps PHP Internals as outlived > the email format and should migrate to a forum format. I think I and man

[PHP-DEV] PR #1723 - fix for crash in mysqli_connect

Hi all, Can someone take a look at this PR to fix a crash with mysqli_connect arising with a mysqlnd refactor in e81ecc80c in master from November: https://github.com/php/php-src/pull/1723 When attempting to mysqlI_connect(‘localhost’, ‘user’, ‘pass), the mysqlnd_conn_data::get_scheme introduc

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

Sascha, > On Jan 12, 2016, at 11:17, Sascha Schumann > wrote: > > Hi John, > >> And it is *not* acceptable. > > May I ask who put you in charge to determine whether something is "acceptable" > or "reprehensible”? *I* avoid internals because *I* believe the conduct here is reprehensible, and

[PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

Stas, On Jan 11, 2016, at 23:24, Stanislav Malyshev wrote: > > Hi! > >> This is yet another example of the toxic internals problem. >> Regardless of one's views on the CoC proposal, the conduct of >> php-internals as a whole has been reprehensible. > > What in your opinion was reprehensive, co

[PHP-DEV] Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[Apologies for the re-post; I’m re-sending this with a new subject because it’s really not about the CoC RFC.] > On Jan 11, 2016, at 19:40, François Laupretre wrote: > > If we want to deal with the reasons why people avoid internals, the let's go > and analyze the problem first ? I will start

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

> On Jan 11, 2016, at 19:40, François Laupretre wrote: > > If we want to deal with the reasons why people avoid internals, the let's go > and analyze the problem first ? I will start asking whether we really want to > attract newcomers. The question may sound ridiculous but I think we don't,

Re: [PHP-DEV] Re: [RFC] array_key_(first|last|index) functions proposal

Hi Andrea, > On Jan 4, 2016, at 12:05, Andrea Faulds wrote: > > Hi John, > > John Bafford wrote: >> Happy New Year, everyone! >> >> I’d like to present the first new PHP RFC for this year, a proposal to add >> functions to easily get the first, l

Re: [PHP-DEV] RFC Operator Overloading in Userspace

Hi Sara, On Jan 2, 2016, at 21:14, Sara Golemon wrote: > > Patricio Tarantino has asked me to help him propose Operator > Overloading in PHP 7.1 (based in part on my operator extension in > PECL). I think we can expose this to usespace as magic methods with > very little overhead (the runtime c

Re: [PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

> On Jan 1, 2016, at 16:38, Bishop Bettini wrote: > > On Fri, Jan 1, 2016 at 3:44 PM, John Bafford wrote: > Happy New Year, everyone! > > I’d like to present the first new PHP RFC for this year, a proposal to add > functions to easily get the first, last, or an arbitra

[PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

Happy New Year, everyone! I’d like to present the first new PHP RFC for this year, a proposal to add functions to easily get the first, last, or an arbitrary key (and value) by index from an array, taking advantage of PHP’s property that arrays are ordered maps. RFC: https://wiki.php.net/rfc/a

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

> On Jan 1, 2016, at 15:20, Johannes Schlüter wrote: > > On Fri, 2016-01-01 at 13:28 -0500, Bishop Bettini wrote: >> Hi, and happy New Year! >> >> Now that the big push for PHP 7 is done, I'd like to revive earlier >> discussions >>

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

Hi Bishop, > On Jan 1, 2016, at 13:28, Bishop Bettini wrote: > > Hi, and happy New Year! > > Now that the big push for PHP 7 is done, I'd like to revive earlier > discussions on the GitHub PR triage team RFC. > Thanks for poking me about this. When I originally proposed the PR triage team a

Re: [PHP-DEV] [VOTE] Void Return Type RFC

There are two particular semantic advantages of void functions I’m not sure have been brought up. A function that always throws an exception can’t have a return value (and checking for one is also semantically and logically incorrect). Since such a function won’t ever return by normal means, t

Re: [PHP-DEV] Let's discuss enums!

> On Sep 17, 2015, at 20:15, Bob Weinand wrote: > >> Am 18.09.2015 um 01:56 schrieb Rowan Collins : >> >> On 18/09/2015 00:16, Marcio Almada wrote: >>> A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points >>> on the linked RFC are compatible to the points you raised so it might

Re: [PHP-DEV] Let's discuss enums!

> On Sep 17, 2015, at 20:06, Bob Weinand wrote: > >> Am 18.09.2015 um 01:52 schrieb John Bafford : >> >> If we’re bikeshedding, one feature I would really like to see, with >> typehinting, is warnings if all cases of an enum aren’t handled in a switch. >>

Re: [PHP-DEV] Let's discuss enums!

On Sep 17, 2015, at 19:16, Bob Weinand wrote: > >> Am 18.09.2015 um 01:06 schrieb Rowan Collins : >> >> This has come up in passing a few times recently, but I'm not sure there's >> ever been a dedicated discussion of it: would it be useful for PHP to have a >> built-in Enumeration type, and i

Re: [PHP-DEV] RFC: Nested enclosing returns

On Mar 21, 2015, at 10:17, Georges.L wrote: > The main purpose of this RFC is *not* to improve the exception system of > PHP but to improve the code logic/hierarchy. > >>> Hi php internals, >>> >>> After some long and deep research i finally decided to write my first RFC >>> about a feature i'

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 17:27, Stanislav Malyshev wrote: > Hi! > >> I provided an array_key_first() implementation awhile ago that was >> first shot down because “too many array_* functions”, and then later >> ignored because I didn’t want to go through the RFC process just to >> add a few function

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:52, Stanislav Malyshev wrote: > Hi! > >>> My proposal is something similar to Pythons slice, in PHP this would look >>> like: >>> >>> $slided = $array[1:4] >>> >>> This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), >>> ignoring the actual key of t

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:27, Alex Bowers wrote: > On 20 March 2015 at 20:10, Sean Coates wrote: > >> That’s no different than `@` being invalid because it’s already in use. > > > The syntax would be [*from:to], which would currently throw a parse error > (since asterisk is required to be place

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:10, Sean Coates wrote: >> I posted four suggestions earlier, >> >> They were: >> >> @ >> & >> * >> ^ >> >> My favourites are the asterisk or caret. > > That’s no different than `@` being invalid because it’s already in use. > > $ php -a > Interactive shell > > php >

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 14:17, Rowan Collins wrote: > It doesn't work *with that syntax*, because -1 is a valid key, just as > $thing[0] can't mean "first value of array" because it already means "value > with key 0". That's why I propose a new syntax such as $thing[@0], > $thing[@-1], etc. I wo

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

On Oct 31, 2014, at 12:15, Ferenc Kovacs wrote: > On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch > wrote: > >> On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57, >> John Bafford wrote: >>> >>>> Hi, >>>> >

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

On Nov 1, 2014, at 08:28, Rowan Collins wrote: > On 1 November 2014 11:53:11 GMT, Pierre Joye wrote: >> Hi, >> >> On Oct 31, 2014 4:57 AM, "John Bafford" wrote: >>> >>> Hi, >>> >>> I would like to propose the creation of a

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

On Nov 1, 2014, at 10:27, Xinchen Hui wrote: > Hey: > > On Sat, Nov 1, 2014 at 7:53 PM, Pierre Joye wrote: >> Hi, >> >> On Oct 31, 2014 4:57 AM, "John Bafford" wrote: >>> >>> Hi, >>> >>> I would like to propose

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

On Oct 31, 2014, at 12:10, Andrea Faulds wrote: > >> On 30 Oct 2014, at 21:57, John Bafford wrote: >> 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

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

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. https://wiki.php.net/rfc/github-pr PHP’s GitHub repository has

[PHP-DEV] VCS Account Request: jbafford

I would like access to edit the wiki and submit RFCs. Thanks, -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow "use( $longname as $alias)" syntax for closures declaration

Things as $sortKey){ return $b->$sortKey - $a->$sortKey; }); } Function parameters are named such that they're relevant to the function, not the caller. Closure variables should be seen as a (special case of) function parameter in that respect. -John -- John Bafford http://bafford.co

Re: [PHP-DEV] PHP class files without

lint (like command line) Actually, it'd be pretty cool to be able to lint a file without having to include runkit (there is a runkit_lint($code)) or make an external call to php -l. > end_code (similar to command line, corresponds with begin_code (also command > line)) > args (a

Re: [PHP-DEV] PHP class files without

ks who did not care for this functionality could then choose to > entirely ignore it. Class library developers who liked it would make > autoloaders available that honored it, freeing end-user developers > from thinking about it. It becomes self-contained, and people who are > writing old-

Re: [PHP-DEV] PHP class files without

, the file extension does not affirmatively indicate the file type or whether or not it can be executed. Also, from a CLI perspective, you don't want extensions in the names of your scripts, because then it causes problems/confusion/extra work if you later decide to change the langu

Re: [PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter

ck into zend_do_receive_arg(), but before I go ahead and do that, I'd like to make sure everyone's happier with this solution than my first. It might also be possible to get rid of zend_arg_info.optional, but I'd need to know how/if it's possible to access the relevant oplines for

[PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter

I'd rather not immediately break code that (until now) worked without warning. Thoughts/comments? -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] New functions: array_key_index(), array_first(), array_last()

" Testing array_last(): string(5) "three" string(4) "last" Testing array_index() with positive offset: string(3) "two" string(6) "middle" Testing array_index() with negative offset: string(3) "one" string(5) "first" Testing array_index() with positive offset past the end of the array: NULL string(5) "first" Testing array_index() with negative offset past the end of the array: NULL string(5) "first" -- John Bafford [EMAIL PROTECTED] http://www.dshadow.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php