Re: [PHP-DEV] [VOTE] noreturn type

On Thu, Apr 1, 2021 at 6:59 AM Matthew Brown wrote: > > On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei wrote: > > > This RFC is using the declaration of the return type, to specify that it > > never returns. As such noreturn or never is a keyword a long the lines of > > public or final, but it is

Re: [PHP-DEV] [RFC] Short functions, take 2

On Wed, Mar 24, 2021 at 8:02 PM Mike Schinkel wrote: > > > On Mar 24, 2021, at 8:39 PM, Larry Garfield wrote: > > > > As requested, splitting off the short-functions RFC to its own thread. > > > > https://wiki.php.net/rfc/short-functions > > > > In response to the feedback that the savings in

Re: [PHP-DEV] Re: Release Managers for PHP 8.1

On Mon, Mar 22, 2021 at 2:24 PM Sara Golemon wrote: > > On Mon, Mar 1, 2021 at 11:09 AM Sara Golemon wrote: > > > This is your early, advance warning that RM selection for the PHP 8.1 > > branch will be coming up in April. Please start thinking about whether or > > not you would like to put

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 9:55 AM Rowan Tommins wrote: > > On 22/03/2021 15:38, Levi Morrison via internals wrote: > > We should dig through the history, because the line before that is in > > conflict: > > > >> Votes should be open for two weeks at m

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier wrote: > > On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski wrote: >> >> >> > On Mar 19, 2021, at 5:47 PM, Levi Morrison >> > wrote: >> > >> > On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller > > > wrote: >> >> >> >> Hey

Re: [PHP-DEV] [VOTE] Fibers

On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller wrote: > > Hey Levi, > >> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski wrote: >> > >> > Greetings everyone! >> > >> > The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers >> > >> > >> > Voting

Re: [PHP-DEV] [VOTE] Fibers

On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski wrote: > > Greetings everyone! > > The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers > > > Voting will run through March 22nd. > > Cheers, > Aaron Piotrowski This is selfish, but I would like

Re: [PHP-DEV] [RFC] Autoloader Classmap

On Tue, Mar 16, 2021 at 11:06 AM Harm Smits wrote: > > Hey, > > First time ever replying so hope all went well. > > I believe the `autoload_set_classmap` function's signature should change > rather to something like this: > > ``` > /** > * Sets the internal autoloader to use the given classmap.

Re: [PHP-DEV] [RFC] Autoloader Classmap

On Mon, Mar 15, 2021 at 12:32 PM Mark Randall wrote: > > On 15/03/2021 17:59, Levi Morrison via internals wrote: > > IMO, these should be the defined case of the class, or we should be > > insensitive about it. It's one thing that our symbols are case > > insensiti

Re: [PHP-DEV] [RFC] Autoloader Classmap

On Mon, Mar 15, 2021 at 11:41 AM Mark Randall wrote: > > Hi Internals, > > I would like to propose the addition of a new mechanism of autoloading > classes - a classmap that will be consulted prior to checking the > spl_autoload_register'd callbacks. > > https://wiki.php.net/rfc/autoload_classmap

Re: [PHP-DEV] Storing the lcname of symbols

On Sun, Mar 7, 2021 at 10:21 AM Levi Morrison wrote: > > Hello! > > Most of PHP's symbols are case insensitive. This means extensions that > need to do things with function and method names end up lowercasing > and hashing the lowercased names, often having to do more memory > allocations too.

Re: [PHP-DEV] Proposal: namespace the SPL

On Thu, Feb 18, 2021 at 7:48 AM Levi Morrison wrote: > > On Thu, Feb 11, 2021 at 9:39 AM Levi Morrison wrote: > > > > Hello, everyone, > > > > There has been a lot of disagreement about namespacing, and people > > seem to have different viewpoints. I am not sure how to reconcile this > > broader

Re: [PHP-DEV] Proposal: namespace the SPL

On Thu, Feb 11, 2021 at 9:39 AM Levi Morrison wrote: > > Hello, everyone, > > There has been a lot of disagreement about namespacing, and people > seem to have different viewpoints. I am not sure how to reconcile this > broader discussion. > > However, there are certain names in the global

Re: [PHP-DEV] Re: Proposal: namespace the SPL

On Sun, Feb 14, 2021 at 5:51 PM Levi Morrison wrote: > > Oof, this is a long one. I'm going to snip some of it but respond to > most things privately; I will also respond to some things publicly > later. > > On Sun, Feb 14, 2021 at 3:44 PM tyson andre wrote: > > > > Hi internals, > > > > > >

Re: [PHP-DEV] Re: Proposal: namespace the SPL

Oof, this is a long one. I'm going to snip some of it but respond to most things privately; I will also respond to some things publicly later. On Sun, Feb 14, 2021 at 3:44 PM tyson andre wrote: > > Hi internals, > > > > 1b. We may switch the direction of this alias in 9.0. > > The new names for

Re: [PHP-DEV] Re: Proposal: namespace the SPL

On Sat, Feb 13, 2021 at 10:57 AM Pierre R. wrote: > > Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit : > > You make some good points, Pierre. Here are my main rebuttals: > > > > 1. "Spl" is already the effective namespace for the SPL

Re: [PHP-DEV] Re: Proposal: namespace the SPL

On Sat, Feb 13, 2021 at 9:25 AM Pierre wrote: > > Le 11/02/2021 à 18:48, Chase Peeler a écrit : > > I think Spl makes sense (there might be a debate over whether it should be > > Spl or SPL though). How feasible is it to create generate a deprecation > > notice when the global version is used? I

Re: [PHP-DEV] Re: Proposal: namespace the SPL

On Thu, Feb 11, 2021 at 10:48 AM Chase Peeler wrote: > > > > On Thu, Feb 11, 2021 at 12:23 PM Levi Morrison via internals > wrote: >> >> On Thu, Feb 11, 2021 at 9:57 AM Mark Randall wrote: >> > >> > On 11/02/2021 16:39, Levi Morrison wrote: &g

Re: [PHP-DEV] Re: Proposal: namespace the SPL

On Thu, Feb 11, 2021 at 9:57 AM Mark Randall wrote: > > On 11/02/2021 16:39, Levi Morrison wrote: > > Let me know what you think. I am hopeful this approach will work because: > > 1. It is focused on a specific area which already has an established > > "namespace", but in name-only (not

Re: [PHP-DEV] [VOTE] PHP\iterable\any() and all() on iterables

On Mon, Feb 8, 2021 at 5:15 PM tyson andre wrote: > > Hi Larry Garfield, > > > > Hi Larry Garfield, > > > > > > > > Hi internals, > > > > > > > > > > Voting has started on https://wiki.php.net/rfc/any_all_on_iterable and > > > > > ends on 2021-02-22. > > > > > > > > > > This RFC proposes to add

Re: [PHP-DEV] Proposal: Add ReverseArrayIterator and ForwardArrayIterator to SPL

On Wed, Feb 3, 2021 at 8:50 AM Nikita Popov wrote: > > On Wed, Feb 3, 2021 at 4:38 PM Levi Morrison wrote: > > > Hello, everyone! > > > > This proposal adds two new classes to the SPL: > > > > - `Spl\ReverseArrayIterator`. It iterates over an array in reverse > > order. It does not duplicate

Re: [PHP-DEV] [VOTE] PHP\iterable\any() and all() on iterables

On Mon, Feb 8, 2021 at 7:33 AM tyson andre wrote: > > Hi internals, > > Voting has started on https://wiki.php.net/rfc/any_all_on_iterable and ends > on 2021-02-22. > > This RFC proposes to add the functions `PHP\iterable\any(iterable $input, > ?callable $callback = null): bool` and

Re: [PHP-DEV] [RFC] Fibers

On Sat, Jan 23, 2021 at 12:11 PM Aaron Piotrowski wrote: > > > > On Jan 18, 2021, at 8:59 AM, Benjamin Eberlei wrote: > > > > Hi Aaron, > > > > this is a very interesting and welcome piece of functionality. I have gone > > through the RFC a few times now, it have never thought about or worked

Re: [PHP-DEV] Proposal: Adding a RewindableKeyValueIterator type allowing mixed/repeated keys

On Sat, Jan 30, 2021 at 5:37 PM tyson andre wrote: > > Hi internals, > > Currently, there don't seem to be any internal classes that can be used to > store a copy of the keys and values of an arbitrary Traversable. > > - This would help in eagerly evaluating the result of a generator in a memory

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

On Thu, Jan 14, 2021 at 8:51 AM Chase Peeler wrote: > > > > On Thu, Jan 14, 2021 at 9:47 AM Levi Morrison via internals > wrote: >> >> > > Am 14.01.21 um 03:45 schrieb Dan Ackroyd: >> > > > If anyone else receives unpleasant emails from h

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

> > Am 14.01.21 um 03:45 schrieb Dan Ackroyd: > > > If anyone else receives unpleasant emails from him (or from anyone > > > else), please either: > > > > > > * forward them to the list for all to see. > > > * forward them to myself, if you'd prefer to not have it dealt with in > > > public > > >

Re: [PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables

I want to make a case for `Spl`. Aside from autoloading (which really ought to be in core but since "spl" is literally in the name of those functions it's kind of stuck), the SPL is mostly data structures and iterator related functionality. It makes perfect sense to me that iterator related

Re: [PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables

On Wed, Jan 6, 2021 at 7:39 AM Levi Morrison wrote: > > On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov wrote: > > > > On Wed, Jan 6, 2021 at 2:28 AM tyson andre > > wrote: > > > > > Hi internals, > > > > > > > I've created a straw poll for the naming pattern to use for `*any()` and > > > `*all()`

Re: [PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables

On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov wrote: > > On Wed, Jan 6, 2021 at 2:28 AM tyson andre > wrote: > > > Hi internals, > > > > > I've created a straw poll for the naming pattern to use for `*any()` and > > `*all()` on iterables. > > >

Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

On Sat, Dec 26, 2020 at 10:02 AM Niklas Keller wrote: >> >> I want to re-iterate my opinion on this discussion thread: anything >> with a prefix is a hard-no from me. Namespaces are literally designed >> for this, and I will not vote "yes" to `iter_all`, `iterable_all`, >> etc, no matter what the

Re: [PHP-DEV] Proposal: Adding SplFixedArray->push() and SplFixedArray->pop()

On Tue, Dec 29, 2020 at 10:04 AM tyson andre wrote: > > Hi Internals, > > Currently, PHP doesn't have a built in memory-efficient array type with > convenient push, pop, and other operations, similar to a list/vector in other > languages. > The closest built in in SPL is >

[PHP-DEV] Name for new, efficient array iterator?

The existing ArrayIterator has a large API surface. In most cases it will duplicate the input array either out of ease of implementation or as consequence of the API. Given that a significant use case for ArrayIterator is to write generic code for Iterators that also work on arrays, it is a pretty

Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

On Sat, Dec 19, 2020 at 1:24 PM tyson andre wrote: > > Hi internals, > > I've created a straw poll for the naming pattern to use for `*any()` and > `*all()` on iterables. > https://wiki.php.net/rfc/any_all_on_iterable_straw_poll > > Background: The RFC

Re: [PHP-DEV] Missing warning for stat(), etc. when invoked with empty string

On Thu, Dec 3, 2020 at 6:30 AM Claude Pache wrote: > > [Of course, I meant `stat()`, not `stats()`. Resending the message with > correct spelling, including in subject line. Sorry.] > > > Hi, > > `stat()` and friends invoked with empty string or null as argument, return > `false` (indicating

Re: [PHP-DEV] phar command

On Mon, Nov 30, 2020 at 8:59 AM Sebastian Bergmann wrote: > Am 30.11.2020 um 16:55 schrieb Nikita Popov: > > My understanding is that packaging libraries as phars is not exactly > > straightforward, and people use different tooling to achieve that. > > While I do not use this "phar" command to

Re: [PHP-DEV] [RFC] Draft - Closure self reference

On Tue, Nov 10, 2020 at 10:09 AM Dan Ackroyd wrote: > > Hello internals, > > For reasons, I was reviewing the conversation where adding closures to > PHP was added, and it reminded me that currently the only way for a > closure to call itself is slightly terribly, so I drafted an RFC: > >

Re: [PHP-DEV] Re: hash BLAKE3

On Fri, Oct 30, 2020 at 6:08 PM Hans Henrik Bergan wrote: > > hmm i'll try again, > made another PR: https://github.com/php/php-src/pull/6393 > > this PR is an alternative to https://github.com/php/php-src/pull/6358 > with some notable differences, > > - this PR is roughly 1700 SLOC, compared to

Re: [PHP-DEV] RFC: execution opcode file without php source code file

On Thu, Oct 1, 2020 at 9:14 AM Dik Takken wrote: > > On 01-10-2020 14:30, Nikita Popov wrote: > > It would be good to know what the actual use-case for this is. If the goal > > here is to distribute pre-compiled PHP code without the source code, then > > this is not going to work without making

Re: [PHP-DEV] The case for transpiled generics

On Thu, Sep 17, 2020 at 1:00 PM Matthew Brown wrote: > > On Sep 17, 2020, at 1:28 PM, Brent Roose wrote: > > But I don't want to get stuck on phrasing, if elidiing is the right term as > > Larry suggests, let's go with it! > > No, the correct term is “type erasure”: >

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

> 3. Better visibility from the JIT (not having to cross userspace/internals > border is good) This is a good point _in theory_, but to me this is just indicative that we need to be able to bundle built-in functions for php-src. Now that we have preloading, I wonder how far off we are from

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

On Thu, Sep 3, 2020 at 8:32 AM Sara Golemon wrote: > > On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer wrote: > > > > I currently use foreach (array_keys($array) as $key) { ... } > > > to avoid complains from code analysers on unused var, is it slower? > > > > one argument brought forward

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

On Tue, Sep 1, 2020 at 2:08 AM Peter Bowyer wrote: > > On Tue, 1 Sep 2020 at 08:59, Marco Pivetta wrote: > > > Did the namespaces ship sail forever? Can we just have those instead, > > please? > > > > To mix metaphors: it sailed, shot down in fiery flames. > > Unfortunately. > > Peter If we add

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

I was actually working on this sort of thing recently. _Technically_, you can support `all`, `any`, and `first` by using a single function: function find_first(iterable $of, callable($value, $key): bool $thatSatistifes): Iterator It converts the $iterable into an Iterator, then calls the

Re: [PHP-DEV] Array map with reset function

On Tue, Aug 25, 2020 at 11:47 AM Michael Voříšek - ČVUT FEL wrote: > > The following code stopped working in PHP 8: > > https://3v4l.org/UlIE3 > > is it a bug or a feature? > > is posting issues like this to internals@lists.php.net email prefered > over opening bug directly? or is there any

Re: [PHP-DEV] Segmentation Fault when trying to call zend_new_array.

On Tue, Aug 25, 2020 at 5:31 AM Ivan Zanev wrote: > > Hello, > > I'm trying to learn a bit more about HashTable in PHP internally and how > memory is allocated when generating arrays with various sizes. I created a > simple C script that would call > > HashTable *ht = zend_new_array(15); > >

Re: [PHP-DEV] Bump minimal OpenSSL version to 1.0.2 in PHP 8.0

On Fri, Aug 14, 2020 at 4:36 PM Gabriel Caruso wrote: > > On Fri, 14 Aug 2020 at 19:16, Jakub Zelenka wrote: > > > Hi, > > > > Just a heads up that I would like to drop support for OpenSSL 1.0.1 in PHP > > 8.0 as it doesn't seem to be supported by any major distro (think that RHEL > > switched

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

> So, a week+ early, then? Surely that means the current vote null and void, to > be reset entirely following a proper discussion period -- one without > concurrent voting. I just want to make sure I understand: there are people who think we haven't discussed the syntax for attributes yet? I

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

On Tue, Aug 4, 2020 at 8:59 PM Levi Morrison wrote: > > > I agree with Theodore's points, including that this is metadata on a > > declaration, not a declaration itself. > > Is this technically true? I haven't peeked at the grammar. I suspect > it is a declaration and not an optional piece of

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

> I agree with Theodore's points, including that this is metadata on a > declaration, not a declaration itself. Is this technically true? I haven't peeked at the grammar. I suspect it is a declaration and not an optional piece of data on a declaration, like say `public`. -- PHP Internals - PHP

Re: [PHP-DEV] 8.0 Feature Freeze happening today

On Tue, Aug 4, 2020 at 12:22 PM Sara Golemon wrote: > > On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov wrote: > > > Sorry, I didn't catch that this message said feature freeze *and branch*. > > > > Please do not create a separate PHP-8.0 branch yet. A separate branch is > > only needed if anyone

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

On Mon, Jul 13, 2020 at 11:37 AM Levi Morrison wrote: > > Hello everyone, > > I'd like to change the default mode of assertion failures to throw. > The current default is to warn. In my opinion this is a bad strategy: > the engine asserted that something that is expected to be true is not, > so

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Thu, Jul 16, 2020 at 9:29 PM Mark Randall wrote: > > On 17/07/2020 02:58, Levi Morrison via internals wrote: > >2. I don't think this is solving any problems, really: > > - Code can move from PHP land to an extension and back again. > > Should the names

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield wrote: > > After some discussion, the namespacing proposal has been again updated. Two > major changes: > > 1) Only engine code goes in \PHP. There's a separate \Ext namespace for > extensions, whether bundled or PECL. > > 2) It establishes that

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

On Wed, Jul 15, 2020 at 10:43 AM Marco Pivetta wrote: > > Hey Larry, > > On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield > wrote: > > > 1) return null, which is a non-type, and thus you need to make the return > > type ?User or User|null, which means the caller *must* always check it's > >

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

On Mon, Jul 13, 2020 at 11:52 AM Marcio Almada wrote: > > I'd like to change the default mode of assertion failures to throw. > > The current default is to warn. In my opinion this is a bad strategy: > > the engine asserted that something that is expected to be true is not, > > so executing

Re: [PHP-DEV] [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects

On Tue, Jul 7, 2020 at 2:47 PM Michał Marcin Brzuchalski wrote: > > Hi internals, > > following recently added alternative to `token_get_all()` in form of a > dedicated class `PhpToken` > I've made a similar proposal for collecting stack traces by introducing > `StackFrame::getTrace()` > and

Re: [PHP-DEV] Convert SplFixedArray to Aggregate?

On Fri, Jun 26, 2020 at 12:45 AM Alex wrote: > > Dear PHP Internals, > > I would like to propose a backwards-incompatible change to > SplFixedArray which fixes the strange and almost certainly unintended > behavior reported in Bug 79404 > (https://bugs.php.net/bug.php?id=79404). > > In short:

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

> I went ahead and changed the implementation to use IteratorForExtensions. > Is anyone overly unhappy with that one? I don't particularly care what color we paint this bike shed. The feature is valuable to me and look forward to it in PHP 8. > @Michal: "ExtensionsIterator" to me sounds like an

Re: [PHP-DEV] [RFC] Reserve keywords in PHP 8

On Mon, Jun 15, 2020 at 2:17 AM Marco Pivetta wrote: > > Hey Ilija, > > On Sat, Jun 13, 2020 at 9:10 PM Ilija Tovilo wrote: > > > Hi internals > > > > I created a new RFC for reserving keywords we might need in PHP 8.x > > versions. > > https://wiki.php.net/rfc/reserve_keywords_in_php_8 > > > >

Re: [PHP-DEV] SPL development interest

In my opinion, another key takeaway: inheritance as a code reuse mechanism can really bite you. SplStack extends SplDoublyLinkedList and this exposes a bunch of methods on a stack that don't make any sense. It also means there are constraints on how well you can optimize the stack, because you

Re: [PHP-DEV] [RFC] [VOTE] Mixed type v2

On Thu, May 7, 2020 at 3:00 AM Máté Kocsis wrote: > > Hi Internals, > > We have just opened the vote on the Mixed type v2 RFC. The voting will be > open for two weeks, until 2020-05-21 12:00 UTC. > > Link: https://wiki.php.net/rfc/mixed_type_v2 > > Cheers, > Máté Somewhat begrudgingly, I have

Re: [PHP-DEV] [RFC] Keep type of reference params

I think changing reference is a bad idea, even if it's behind some sort of declare or ini setting or what-have-you. I do support `inout`, which has similar high-level outcomes: the current value is fed in, and when the function returns it has a new value. I think we should use `&` at the call

Re: [PHP-DEV] Re: [RFC] Always available JSON extension

Have we reached out to package maintainers for OS distributions that are not bundling json today to make sure all their concerns are resolved?

Re: [PHP-DEV] [VOTE] match expression

On Tue, Apr 28, 2020 at 6:58 PM Larry Garfield wrote: > > On Tue, Apr 28, 2020, at 7:37 PM, Levi Morrison via internals wrote: > > > One issue that was discussed a few weeks ago, and led to the current > > > syntax, was too many variations within the switch syntax; of cou

Re: [PHP-DEV] [VOTE] match expression

> One issue that was discussed a few weeks ago, and led to the current syntax, > was too many variations within the switch syntax; of course, trying to do it > all in one syntax is perpetuating that problem. However, I think Rowan has > suggested a syntax that may be sufficiently

Re: [PHP-DEV] Any interest in a list type?

On Thu, Apr 23, 2020 at 8:16 AM Matthew Brown wrote: >> >> IIRC, they switched from object semantics to value semantics (like PHP >> arrays). Can someone more knowledgeable confirm? > > > Yes, sorry – Hack introduced the vec type (with value semantics) in 2016 > after they'd experimented first

Re: [PHP-DEV] Any interest in a list type?

On Wed, Apr 22, 2020 at 11:03 PM Matthew Brown wrote: > > > This is the *design* process for a language, and it's important... > Stepping back to reconsider how collections work generally, and how we can > improve them in a graceful way that leads to a clean end-state, would be > very valuable. >

Re: [PHP-DEV] Resurrecting named parameters

On Tue, Apr 7, 2020 at 6:45 AM Nikita Popov wrote: > > ## LSP checks for parameter names > > Parameter names currently have no particular significance in PHP, only > their position in the signature is important. If named parameters are > introduced (in a way that does not require opt-in at the

Re: [PHP-DEV] [RFC][POLL] Switch expression

On Tue, Mar 31, 2020 at 12:51 PM Ilija Tovilo wrote: > > Hi internals > > A few days ago I opened the discussion on the switch expression RFC: > https://wiki.php.net/rfc/switch_expression > > There's been a fundamental disagreement on what the switch expression > should actually be. Due to the

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

The current RFC text is not consistent with using `=` or `=>` for the assignments. The assignment `=` is vastly more common, though, and I don't understand why if we are using an array syntax we aren't using `=>`. I intend to vote no. I agree that we need to do something in this space, but this

[PHP-DEV] Removing warning for failed include

It's bothered me for quite some time that a failed include emits a warning. This is because it's by design that the author chose `include` and not `require`. It's _expected_ that it may fail and they are okay with that. As an example, consider a classic autoloading case. It could be as simple and

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

To me, this is almost a good idea. However, I would want regular type checking, not casts. Importantly, regular type checks would fit well on allowing array destructuring directly in function signatures, which would basically be a form of named parameters. -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis

> In short: I believe our biggest potential win is to focus on 3 RFCs: > > * Constructor Promotion I would vote yes on this, assuming the implementation is sane. > * Named parameters This one is tricky -- there are tradeoffs of every approach I've seen proposed. I have an idea for another way to

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

> IMO, PECL is an antiquated system that needs a successor, in much the same > way Composer is the successor to PEAR. I think there are folks working on a > solution for this, but I’m not sure where they are in their efforts. If we > could make extensions as easy to package, distribute, and

Re: [PHP-DEV] Making mysqli easier to use with parameters

> > $in_sql = implode(',', array_fill(0, count($ids), '?')); > > $sql = 'SELECT id, name FROM user WHERE id IN (' . $in_sql . ')'; > > if ($statement = $db->prepare($sql)) { > > $params = [str_repeat('i', count($ids))]; > foreach ($ids as $key => $value) { >

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

It is my opinion that voting "no" should not require any more effort than voting "yes". Voting "no" is just as reasonable as voting "yes". We do not need to justify our opinion. The burden of documenting the historical reasons for "no" should be placed on the RFC authors, not the voters. -- PHP

Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties

Chiming in to express my disappointment that `final` wasn't a voting choice. 1. It's already reserved, so we don't have to worry about a new keyword. 2. Another very popular language that is similar to PHP already uses it (Java). I voted no for a variety of reasons, which includes: - It

Re: [PHP-DEV] Re: [RFC] Validation for abstract trait methods

On Tue, Mar 3, 2020 at 8:01 AM Nikita Popov wrote: > > On Fri, Feb 7, 2020 at 11:32 AM Nikita Popov wrote: > > > Hi internals, > > > > I've sent a mail about this before, but as this turned into a bit of a > > larger change (also allowing "abstract private" methods in traits) and > > there's

Re: [PHP-DEV] Support rewinding of generators

On Wed, Feb 26, 2020 at 4:47 AM Nikita Popov wrote: > > Hi internals, > > Generators currently do not support rewinding -- or rather, only support it > if the generator is at/before the first yield, in which case rewinding is a > no-op. > > Generators make it real breeze to implement primitives

Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again)

Just chiming in to voice strong support for this RFC. This is a key piece toward making PHP code statically analyzable. If it becomes required at the call site, such as in an edition of the language, it will significantly enhance the ability to reason about code and probably make it more correct

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

On Thu, Feb 13, 2020 at 2:48 AM Nikita Popov wrote: > > Hi internals, > > This has been discussed a while ago already, now as a proper proposal: > https://wiki.php.net/rfc/token_as_object > > tl;dr is that it allows you to get token_get_all() output as an array of > PhpToken objects. This reduces

Re: [PHP-DEV] [RFC]

I have three immediate thoughts: 1. It should be `fn` or `function`; reserving a new word even if it's contextual is pointless here. 2. It should support methods. 3. It should return a closure, not a string. The reason is for consistency with methods, where we want to capture the scope at the

Re: [PHP-DEV] [RFC - discussion] __toArray()

Sorry if it's been said in the discussion so far, but I do not see why `print_r` should convert anything to an array. It accepts multiple kinds of types including strings, numbers, and so on, and I think adding this behavior to `print_r` is a different thing than wanting a standard way for objects

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

We are predominantly volunteers, and should keep that in mind for these kinds of things. In my opinion, a timeline of 6 months is definitely too short. Maybe something like 3 years would be more appropriate. And if we do remove stale voting privileges it should be easy to get them back again, and

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

1. The main issue is that the clause for representatives from the PHP community was never fleshed out. In particular: - Which frameworks, cms, tools, etc qualify and what constitutes a lead developer? - How will those with php.net choose these representatives? If it's by vote, what is the

Re: [PHP-DEV] Bump required libcurl version to 7.17.1

On Sat, Jan 11, 2020 at 4:57 AM Olumide Samson wrote: > > Why not the most recent and stable version? > > I'm thinking modern version has many bugs fixed and many vulnerabilities > fixed, even with improvements that make things more faster and lighter... Using the most recent version would make

<    1   2