Re: [PHP-DEV] Two new functions array_first() and array_last()

> > This is simply not true, 0 is not always the first key in a list, > > especially after filtering it. Hence there is a need for this function > > in the first place. > > Just to clarify this point: If 0 is not the first key, then it's not a list. > After filtering a list, you get an array that

Re: [PHP-DEV] Two new functions array_first() and array_last()

> c) Two such functions were proposed and rejected during the > array_key_first/last RFC > (https://wiki.php.net/rfc/array_key_first_last) > > Yes, that was in 2018. At that time, functions like str_contains() or > str_starts_with() wouldn't have even come into existence, just because > there was

Re: [PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov wrote: > > Hi internals, > > The vote on "A new JIT implementation based on IR Framework" RFC is started. > > https://wiki.php.net/rfc/jit-ir > > Thanks. Dmitry. >From the RFC: > The details of the IR framework are complex. This [presentation][1]

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

> Please find the following resources for your references: > > RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023 > Discussion Thread: https://externals.io/message/121004 > Feedback by a Hashcat team member on Fediverse: > https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075 I

Re: [PHP-DEV] [VOTE] Support optional suffix parameter in tempnam

On Sun, Aug 27, 2023 at 4:20 AM Tim Düsterhus wrote: > > Hi Athos > > On 8/27/23 04:02, Athos Ribeiro wrote: > > I am moving this RFC [1] to the voting phase. Voting will be open for the > > next 2 weeks, until September 10th, as per https://wiki.php.net/rfc. > > > > [1]

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

On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to

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

On Mon, Jul 3, 2023 at 2:54 AM Tim Düsterhus wrote: > > Hi > > On 7/3/23 02:11, Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > > the past 6 days, and the feature freeze deadline is fast approaching > > for PHP 8.3, so I'm moving this to vote. It'll

Re: [PHP-DEV] [RFC] [VOTE] Deprecate remains of string evaluated code assertions

On Wed, Jun 28, 2023 at 10:09 AM G. P. B. wrote: > > Hello internals, > > I'm opening the vote for the > Deprecate remains of string evaluated code assertions RFC: > https://wiki.php.net/rfc/assert-string-eval-cleanup > > It will last for two weeks and end on Wednesday the 12th of July > > Best

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

On Tue, Jun 20, 2023 at 9:46 PM Levi Morrison wrote: > > On Tue, Jun 20, 2023 at 6:29 AM David Gebler wrote: > > > > On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote: > > > > > > I like the idea of this RFC - in fact it's one which has been near top > > > > of > > > > my wishlist for PHP

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

On Sat, Jun 17, 2023 at 4:10 PM David Gebler wrote: > > On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals > wrote: >> >> >> I am moving my RFC for interface default methods to discussion: >> https://wiki.php.net/rfc/interface-default-methods. >

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

On Fri, Jun 16, 2023 at 11:51 AM Deleu wrote: > > > On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals > wrote: >> >> Hello, PHP Internals, >> >> I am moving my RFC for interface default methods to discussion: >> https://wiki.php.net/rfc

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

On Thu, Jun 15, 2023 at 3:37 PM Ilija Tovilo wrote: > > I am moving my RFC for interface default methods to discussion: > > https://wiki.php.net/rfc/interface-default-methods. > > The RFC doesn't mention default implementations for static methods. > I'm not sure there's a use case but it might

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

On Thu, Jun 15, 2023 at 9:16 AM Tim Düsterhus wrote: > > Hi > > On 6/15/23 17:08, Deleu wrote: > > The feature may introduce a new way for *Users of PHP* to break BC with > > *Other Users of PHP*. The language change itself has no impact on PHP code > > written prior to the feature. The

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

> I still believe this information should be added to the RFC as the risk > of adding new methods to an interface which collide with existing > methods in implementations of that interface is very real, though I > agree with Deleu that this BC impact is not so much of the RFC, but of > what can

[PHP-DEV] [RFC] Interface Default Methods

Hello, PHP Internals, I am moving my RFC for interface default methods to discussion: https://wiki.php.net/rfc/interface-default-methods. This can be a useful tool for a few reasons: 1. It can make implementing an interface easier when certain methods can be implemented by other methods in the

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Wed, Jun 14, 2023 at 4:06 AM Derick Rethans wrote: > > On Tue, 13 Jun 2023, Nicolas Grekas wrote: > > > > I'm going to nitpick on the newly suggested names and argument order for > > > the > > > DatePeriod factory methods — althoughI do agree that they need to get > > > created: > > > > > >

Re: [PHP-DEV] [RFC] [Discussion] Clone with

On Mon, Apr 17, 2023 at 12:32 AM Máté Kocsis wrote: > > Hi Everyone, > > Quite some time after mentioning the "clone with" construct the first time > (at the end of the > https://wiki.php.net/rfc/write_once_properties#run-time_behaviour section), > finally I managed to create a working

Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`

On Tue, May 30, 2023 at 5:35 AM Boro Sitnikovski wrote: > > Hello all, > > As per the How To Create an RFC instructions, I am sending this e-mail in > order to get your feedback on my proposal. > > I propose introducing a function to PHP core named `array_group`. This > function takes an array

Re: [PHP-DEV] Final anonymous classes

I am not sure about making them final by default. I think it's a more consistent language design to allow `new final class()` as you originally proposed. Although I don't know why anyone would want to extend anonymous classes, we can see that people do, in fact, do it. I don't see why we couldn't

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

On Fri, Apr 28, 2023 at 4:01 AM Jakub Zelenka wrote: > > Hi, > > The vote is now open for the RFC about introduction of the PHP Technical > Committee: > > https://wiki.php.net/rfc/php_technical_committee > > Regards > > Jakub Do we really need this level of bureaucracy? I mean... I know

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

On Thu, Apr 20, 2023 at 9:57 PM Deleu wrote: > > > > On Thu, Apr 20, 2023 at 8:23 PM Levi Morrison via internals > wrote: >> >> I'm going to stop here. Two big things: >> >> 1. I think reducing verbosity can be left for the future. We don't >>

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

On Thu, Apr 20, 2023 at 11:25 AM Larry Garfield wrote: > > Hi folks. This is a pre-discussion, in a sense, before a formal RFC. > Nicolas Grekas and I have been kicking around some ideas for how to address > the desire for typed callables, and have several overlapping concepts to > consider.

Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments

On Fri, Jan 27, 2023 at 8:54 AM Larry Garfield wrote: > > On Fri, Jan 27, 2023, at 3:00 AM, Andreas Heigl wrote: > > Hey Folks. > > > > I think it would be a good idea to deprecate calling ldap_connect with 2 > > parameters host and port. > > > > Wait: What? > > > > Currently there are three ways

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

It seems to me that if you truly want to clean up this specific part of the language, you are going to have to play the long game: 1. New functions are added for the perl behavior of string increment and decrement. No warnings are given in code, but call-outs are made in upgrading and other

Re: [PHP-DEV] RFC: rules for #include directives

As commented yesterday on one of the PRs, I strongly agree with the cleanups. Our code has implicit dependencies and if you reorder the includes in the same file, you can break builds. That shouldn't ever happen. I also agree that dtrace breaking is a failure of CI and testing, not necessarily

Re: [PHP-DEV] ARRAY_UNIQUE_IDENTICAL option

A bit off topic, but not entirely: In my opinion, adding another flag isn't the _real_ fix. Any function which does comparisons should take a callable for users to provide any comparison they wish. An iteratively better API would be: function array_unique(list $array, callable(T $a, T $b):

Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2

FYI, it is also noted in the [UPGRADING][1] file: > - Core: > . The iterable type is now a built-in compile time alias for > array|Traversable. >Error messages relating to iterable will therefore now use > array|Traversable. >Type Reflection is preserved for single iterable (and

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

> > There's other functionality that I was less certain about proposing, such > > as `iterable\keys(iterable $iterable): array`, > > which would work similarly to array_keys but also work on Traversables > > (e.g. to be used with userland/internal collections, generators, etc.) > > I assume this

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

> Namespaces were chosen after feedback on my previous RFC, > and I believe `iterable\` follows the guidance from > https://wiki.php.net/rfc/namespaces_in_bundled_extensions and > https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl I support this general direction

Re: [PHP-DEV] Proposal to incrementally improve timeout and signal handling

This kind of thing requires careful thought. My first glance through it looks good and I definitely want PHP to stop abusing the SIGPROF signal because it prevents usage by actual profilers, which is annoying. Full disclosure: I write a profiler for my job. In addition, I think that there should

Re: [PHP-DEV] Newcomer, PHP pre-processing, Magic Constants __FILE__ and __LINE__ override with #line like in C

> I think you're also greatly over-estimating how large the startup cost is in > practice. It's real, certainly, but unless you have several nested > microservices a well-made framework should have a fairly small overhead. I want to share my experience that some users have very slow file I/O,

Re: [PHP-DEV] [Concept] Extension methods

> What are your thoughts? It's a fantastic feature that I've used in Rust, although there are some differences. First, it doesn't work for regular methods -- they have to be part of a trait. Secondly, in general a trait can only be implemented for a given type if it is in the package which

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

On Tue, Jul 5, 2022 at 3:39 PM shinji igarashi wrote: > > Hello internals, > > I've started the vote for the Constants in Traits RFC: > https://wiki.php.net/rfc/constants_in_traits > > The vote will end on 19. July 2022. > > Thanks! > > -- > Shinji Igarashi > > -- > PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron wrote: > > Hi all, > > > > - The new CurlUrl class should probably be immutable from the start. It > > was my biggest mistake not to do that with DateTime. > > > > > After thinking about it and some discussions, I followed Derick's >

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron wrote: > > Hi, > > Following our discussions we had on the subject of the new Curl URL API, > and other curl improvements. I decided to only focus on adding the new Curl > URL API and put aside all other improvements. Here is the RFC that reflects

Re: [PHP-DEV] Make iterator_to_array() accept all iterables

On Fri, Jun 17, 2022 at 9:28 AM G. P. B. wrote: > > On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus wrote: > > > Hi Internals > > > > I've come across a case where it would've been useful if > > `iterator_to_array()` would accept iterable instead of Traversable to > > avoid checking whether the

Re: [PHP-DEV] [RFC] Disjunctive Normal Form Types

> DNF types are a way to mix intersection and union types together in a > single type. > For example: > [...] > - (Traversable)|array I have yet to read the fine print, but this example was a motivating case for me to start down the union-types road years ago. I would be very happy to finally

Re: [PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

On Sat, Mar 12, 2022 at 10:32 AM G. P. B. wrote: > > I've started voting for the Allow null and false as stand-alone types RFC: > https://wiki.php.net/rfc/null-false-standalone-types > > Voting will last for 2 weeks until 26th of March. > > Best regards, > > George P. Banyard Hello, I have

Re: [PHP-DEV] Adding `final class Deque` to PHP

I think this RFC is in much better shape now. The last thing I'll personally push for is dropping `get` and `set`. I'm not sure about those names, and the functionality is already provided by `offsetGet` and `offsetSet`, albeit through `mixed` instead of `int`, but I think this sort of cleanup

Re: [PHP-DEV] [Help] Reason on when to declare and protect ZEND_API function

On Thu, Jan 20, 2022 at 1:56 AM Su, Tao wrote: > > Hello internals, > > I am trying to read Zend header files to understand its functional interfaces, > but have got confusion and anybody knows why zend_startup_system_id() and > zend_finalize_system_id() > do not have to be protected by

Re: [PHP-DEV] [VOTE] Add array_group function

On Tue, Dec 21, 2021 at 1:48 AM Hassan Ahmed <7sno...@gmail.com> wrote: > > Hello all, > > I would like to start a voting phase for this RFC: Add array_group function > > > Regards, > > ~Hassan This RFC has mistakes in its opening

Re: [PHP-DEV] Re: PHP-FPM process management woes

As Jakub mentioned, exactly one MINIT/MSHUTDOWN per process will only fix one of your problems, but I do like the step in that direction. I express my sympathy and condolences: I've had my own share of woes with the fact that env var and INI changes are not complete during MINIT due to fcgi

Re: [PHP-DEV] Surveying interest regarding CMake

On Fri, Dec 17, 2021 at 6:49 AM Horváth V. wrote: > > One thing I forgot to ask is what minimum CMake version should php-src > support in its build scripts? For reference, please take a look at > repology.org for the packaging status of CMake across a lot of software > distributions:

Re: [PHP-DEV] Surveying interest regarding CMake

On Thu, Dec 16, 2021 at 1:13 PM Horváth V. wrote: > > > My main question would be how this will affect 3rd party extensions, > > which are currently using autoconf. Will they need to migrate to > > cmake, or will we have to effectively maintain both build systems? > > Unless 3rd party extensions

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

> if hosting it ourself is a priority, i suggest looking into GitLab’s > Community Edition, which is entirely open source, > and the GNOME project moved from Bugzilla to GitLab CE in 2018, > here's how that worked out, 2 years later: > https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/ >

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

> Based on the received feedback, I've updated the RFC to instead provide an > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > dynamic properties. As previously discussed, this won't allow us to > completely remove dynamic properties from the language model anymore, but > it

Re: [PHP-DEV] [Pre-Vote Announcement] Move RNG functions Random Extension

On Mon, Oct 4, 2021 at 4:21 AM Nikita Popov wrote: > > On Wed, Sep 22, 2021 at 1:21 PM Go Kudo wrote: >> >> The voting phase for the following RFCs will begin as soon as two weeks >> have passed. >> >> https://externals.io/message/115975 >> >> I don't see any particular discussion, so I'm

Re: [PHP-DEV] [RFC] Allow null as standalone type

On Tue, Oct 5, 2021 at 8:08 AM Côme Chilliet wrote: > > Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a écrit : > > If we make this change, I would however suggest to also support "false" as > > a standalone type. I think this change primarily has benefits from a > > typesystem completeness

Re: [PHP-DEV] [RFC] Allow null as standalone type

On Sat, Oct 2, 2021 at 9:07 AM G. P. B. wrote: > > Hello internals, > > I'm proposing a new RFC to make 'null' usable as a standalone type. > > RFC: https://wiki.php.net/rfc/null-standalone-type > GitHub PR: https://github.com/php/php-src/pull/7546 > > Best regards, > > George P. Banyard I don't

Re: [PHP-DEV] Static (factory) methods in attributes and initializers

I'm not exactly sure what you are proposing. However, it's always worth noting other languages which have something in the feature space, and Dart has both named constructors and factory constructors. You should start with researching what they do, and what other languages may have the same as

Re: [PHP-DEV] BC breaking changes in PHP 8.1

> As somebody who's been contributing to and maintaining OSS libraries > forever (since 2002), the pace of change of PHP is, frankly, ridiculous. I > can keep up with patches. I can keep up with new features. But BC breaks > EVERY YEAR just creates churn. I've spent most of the past 18 months

Re: [PHP-DEV] Adding `final class Deque` to PHP

> "Maximum size" shouldn't be an issue for `Deque` specifically, it's a > `size_t`. It isn't an issue for SplFixedArray and ArrayObject. > (or for > PHP would just encounter a fatal error due to either You wrote a lot, but unfortunately it was based on a misunderstanding. In some languages you

Re: [PHP-DEV] Adding `final class Deque` to PHP

The name "deque" is used in the standard library of these languages: - C++: std::deque - Java: java.util.Deque (interface) - Python: collections.deque - Swift: Collections.Deque (not standard lib, apparently, but Apple official? Don't know Swift) - Rust: std::collections::VecDeque And these

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> * Whether or not contains() needs a comparison callback in my mind depends > mainly on whether or not the operator overloading RFC passes. If it does, > then contains() can/should use the __compareTo() method on objects. If it > doesn't, then there needs to be some other way to compare

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> I'd considered using a signature of `setSize(int $size, mixed $value = null)` > to allow using something other than null > but decided to leave that to a followup proposal if it passed. Rust and C++ both accept a value to pad, there's no reason to restrict this to only null. Go ahead and make

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

> > - `contains` also doesn't have a comparator. > > I was considering proposing `->any(callable)` and `->all(callable)` > extensions if this passed. > I'm not quite sure what you mean by a comparator for contains. There'd have > to be a way to check if a raw closure is contained. I mean that

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

On Thu, Sep 16, 2021 at 8:10 PM tyson andre wrote: > > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add > `final class Vector` to PHP. > > PHP's native `array` type is rare among programming language in that it is > used as an associative map of values,

Re: [PHP-DEV] Alias stdClass to DynamicObject?

On Mon, Sep 6, 2021 at 9:29 AM Nikita Popov wrote: > > Hi internals, > > In the thread for deprecation of dynamic properties, Rowan suggested that > we alias "stdClass" to "DynamicObject" in > https://externals.io/message/115800#115802. I wanted to split this > discussion off into a separate

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

> And why not adding an extra keyword, such as: > > ``` > dynamic class Foo { } // Dynamic allowed > class Bar {} // Dynamic disallowed > ?> > ``` I am opposed. IMO it's not worth adding anything to the language to preserve this existing behavior other than allowing `__get`/`__set`, etc, which

[PHP-DEV] What is the history of the split between zend extensions and modules?

Today, zend extensions and modules have different features they support. I'm curious why this split came to be. Why did they need to be different types of shared objects? I am tentatively thinking about proposing for PHP 8.2 or 9.0 that the `zend_extension` struct holds a `zend_module_entry` by

Re: [PHP-DEV] [RFC] Nullable intersection types

> That is a strange attitude. You are saying that you rather see a release with > a [known] flaw than actually trying to find the best solution. Sorry, but sometimes features take time either due to technical reasons (variance was difficult to get right this way), or due to disagreements in

Re: [PHP-DEV] [RFC] Nullable intersection types

> As you note in the RFC, PHP already defines `|` as having a lower > precedence than `&`, so `X & Y | null` can only be interpreted as > `(X & Y) | null`. This is consistent with other languages such as > TypeScript, where `A & B | C & D` is parsed as `(A & B) | (C & D)`. > [2] > > Since

Re: [PHP-DEV] [RFC] Nullable intersection types

On Fri, Jul 23, 2021 at 6:37 AM Derick Rethans wrote: > > From the RFC: «Taking all these elements into account, the preference > of... and thus to use the "?X" syntax». > > I think this would be a mistake. You touch upon operator precedence, and > needing to know whether | or & is higher, and

Re: [PHP-DEV] Request for karma to vote on RFCs

On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov wrote: > > On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm > wrote: > > > Hey. > > I would like to get karma to be able to vote on RFCs. I understand that > > voting karma isn’t usually given out to people who write their first > > mailing list entry. >

Re: [PHP-DEV] [Vote] Pipe operator v2

> Pol Dellaiera (https://github.com/drupol) has done a lot of work around > this stuff, specifically the type inference bit, in > https://github.com/loophp/combinator , so I see hope to get better types at > a later stage. I don't see a pipe combinator in there, but maybe I can't see it through

Re: [PHP-DEV] Type casting syntax

On Sun, Jul 11, 2021 at 5:19 PM Larry Garfield wrote: > > On Sun, Jul 11, 2021, at 5:30 PM, Levi Morrison via internals wrote: > > I like Rust's From and TryFrom traits, which allow types to define > > conversions into or from other types. The From trait always succeeds, > &

Re: [PHP-DEV] Type casting syntax

I like Rust's From and TryFrom traits, which allow types to define conversions into or from other types. The From trait always succeeds, and TryFrom can fail. However, it's not a "cast" -- the user calls an `into`/`try_into` or `from`/`try_from` methods. I would be supportive of defining official

Re: [PHP-DEV] [VOTE] First-class callable syntax

On Wed, Jul 7, 2021 at 2:40 PM Ralph Schindler wrote: > > > > > > > It would theoretically be: > > > > $fn = MyController::myAction(...); > > > > It currently errors: > > > >> Fatal error: Uncaught Error: Non-static method MyController::myAction() > >> cannot be called statically > > > > I

Re: [PHP-DEV] [VOTE] First-class callable syntax

On Fri, Jul 2, 2021 at 10:32 AM Ralph Schindler wrote: > > > > This RFC uses a syntax that is forward-compatible with partial function > > application. Should it not be accepted, I'll explore alternative syntax > > possibilities. > > Given the choice of syntax in this proposal (which I do

Re: [PHP-DEV] [Vote] Partial Function Application

On Tue, Jun 29, 2021 at 12:05 PM Larry Garfield wrote: > > On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote: > > On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote: > > > (Extracted from the "Pipe Operator, take 2" thread) > > > > > > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield >

Re: [PHP-DEV] [Vote] Partial Function Application

On Mon, Jun 28, 2021 at 10:32 AM Olle Härstedt wrote: > > On Thu, 24 Jun 2021, 18:02 Larry Garfield, wrote: > > > On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote: > > > Hi folks. The vote for the Partial Function Application RFC is now > > > open, and will run until 30 June. > > > > > >

Re: [PHP-DEV] [Vote] Partial Function Application

On Thu, Jun 24, 2021 at 11:12 AM Claude Pache wrote: > > > > > Le 24 juin 2021 à 18:02, Larry Garfield a écrit : > > > > On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield wrote: > >> Hi folks. The vote for the Partial Function Application RFC is now > >> open, and will run until 30 June. > >> >

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Mon, Jun 21, 2021 at 2:25 PM Craig Francis wrote: > > On Sat, 12 Jun 2021 at 18:00, Craig Francis > wrote: > > > I'd like to start the discussion on the is_literal() RFC: > > https://wiki.php.net/rfc/is_literal > > > > > To recap, > > - We have chosen the name is_trusted(), based 18 votes

Re: [PHP-DEV] [Vote] Partial Function Application

> The thing is, new developers don't think *anything*. There's nothing > intrinsically more "natural" about procedural code vs functional code, or OOP > code, or whatever other paradigm. They're all artificial as far as the brain > is concerned. People who start off in an OOP language, and

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

> Over half of the objections are to functionality, over half to unspecified > reasons, I support people choosing not to directly respond with their unspecified reasons, but if anyone is open to sharing I would appreciate them doing so. I agree with Nikita that the concept is useful, and with

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

On Thu, Jun 10, 2021 at 8:40 AM Pierre wrote: > > Le 10/06/2021 à 16:16, tyson andre a écrit : > > So I'm probably changing this to `ImmutableTraversable` as a short name for > > the functionality, > > to make it clear arguments are eagerly evaluated when it is created. > > (ImmutableSequence

Re: [PHP-DEV] Re: Allow combining arg unpacking and named args

On Thu, Jun 10, 2021 at 7:14 AM Nikita Popov wrote: > > On Tue, May 25, 2021 at 4:18 PM Nikita Popov wrote: > > > Hi internals, > > > > Currently, argument unpacking (...$foo) cannot be combined with named > > arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y, > > ...$args)

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

On Wed, Jun 9, 2021 at 8:12 AM tyson andre wrote: > > Hi Levi Morrison, > > > > > Hi internals, > > > > > > > > > I've created a new RFC https://wiki.php.net/rfc/cachediterable adding > > > > > CachedIterable, > > > > > which eagerly evaluates any iterable and contains an immutable copy > > > >

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

On Tue, Jun 8, 2021 at 10:47 PM Levi Morrison wrote: > > On Tue, Jun 8, 2021 at 6:22 PM tyson andre wrote: > > > > Hi internals, > > > > > I've created a new RFC https://wiki.php.net/rfc/cachediterable adding > > > CachedIterable, > > > which eagerly evaluates any iterable and contains an

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

On Tue, Jun 8, 2021 at 6:22 PM tyson andre wrote: > > Hi internals, > > > I've created a new RFC https://wiki.php.net/rfc/cachediterable adding > > CachedIterable, > > which eagerly evaluates any iterable and contains an immutable copy of the > > keys and values of the iterable it was

Re: [PHP-DEV] Re: [RFC] Partial function application

On Sat, May 29, 2021 at 3:50 PM Mark Randall wrote: > > On 25/04/2021 20:25, Larry Garfield wrote: > > It includes an implementation by Joe Watkins that is already about 95% > > complete. (There's some edge cases he's still sorting out, but all of the > > typical cases should work already.)

Re: [PHP-DEV] Allow combining arg unpacking and named args

On Tue, May 25, 2021 at 8:18 AM Nikita Popov wrote: > > Hi internals, > > Currently, argument unpacking (...$foo) cannot be combined with named > arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y, > ...$args) are rejected by the compiler. > >

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

On Fri, May 21, 2021 at 1:01 PM Calvin Buckley wrote: > > Hi internals@, > > I maintain an extension and I suspect there are some issues in the code. As > such, I’ve been trying various tools to try to make it easier to catch the > issues. (For the curious: I’ve tried *San, which I feel doesn’t

Re: [PHP-DEV] [RFC] Partial function application

> I don't know what the answer is here, I'm reading through the entire thread > and RFC again and trying to better formulate in my mind how I'd [like to] > reason about this in terms of syntax. But the more I think about it, the > more I realise much as I loved the idea when I first read the RFC,

Re: [PHP-DEV] [RFC] Partial function application

Joe Watkins has successfully worked out some bugs that also enable more powerful behavior. Thanks to Nikita and any others who worked with Joe on fixing these issues and reviewing the PR. The short of it is that re-ordering parameters when using named placeholders is now technically possible. We

Re: [PHP-DEV] [RFC] Partial function application

On Thu, May 13, 2021 at 2:31 PM Sara Golemon wrote: > > On Thu, May 13, 2021 at 2:31 PM Andreas Hennings > wrote: > > > 1. Serializing: > > But outside of the above cases it should be technically possible, or not? > > > > > I suspect that the limitations you cite make any kind of general >

Re: [PHP-DEV] [RFC] Partial function application

On Thu, May 13, 2021 at 7:44 AM Levi Morrison wrote: > > On Thu, May 13, 2021 at 2:45 AM someniatko wrote: > > > > > Greetings, Internalians! > > > > > > I would like to offer for your consideration another RFC, specifically > > > syntax for partial function application. > > > > > >

Re: [PHP-DEV] [RFC] Partial function application

On Thu, May 13, 2021 at 2:45 AM someniatko wrote: > > > Greetings, Internalians! > > > > I would like to offer for your consideration another RFC, specifically > > syntax for partial function application. > > > > https://wiki.php.net/rfc/partial_function_application > > Thank you again for one

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

On Wed, May 12, 2021 at 10:13 AM David Gebler wrote: > > On Wed, 12 May 2021, 09:13 Nikita Popov, wrote: > > > > > I think we would be better off disabling -a completely if readline is not > > available, and exit with a helpful error message. I've opened > >

Re: [PHP-DEV] Discussion: Object-scoped RNG

On Wed, May 12, 2021 at 8:58 AM Nikita Popov wrote: > > On Wed, May 12, 2021 at 4:51 PM Levi Morrison via internals > wrote: >> >> > Also, I am happy to see that Nikita's rules for namespace assignment to >> > extensions have been approved. I'm going to us

Re: [PHP-DEV] Discussion: Object-scoped RNG

> Also, I am happy to see that Nikita's rules for namespace assignment to > extensions have been approved. I'm going to use the `RNG` namespace. Just to be clear, you can only use `RNG` as a namespace if the extension is named `ext/rng`. You cannot add namespaced things to `standard` nor `SPL`

Re: [PHP-DEV] Discussion: Object-scoped RNG

On Tue, May 11, 2021 at 6:58 AM Go Kudo wrote: > > Hi internals. > > I previously proposed an object scope RNG implementation inside. > However, the RFC was rejected after a vote. > > https://wiki.php.net/rfc/object_scope_prng > > Vote: https://externals.io/message/113888 > Discussion:

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Tue, Apr 27, 2021 at 12:12 PM David Gebler wrote: > > > > On Tue, Apr 27, 2021 at 6:56 PM Levi Morrison > wrote: >> >> I think the conversation on final classes being "bad" has gone on long >> enough. You don't like final, and you don't want to see more features >> like it being added, such

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

I think the conversation on final classes being "bad" has gone on long enough. You don't like final, and you don't want to see more features like it being added, such as sealed. Point taken. Now please stop dominating the discussion, thank you. -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] [RFC] Partial function application

On Sun, Apr 25, 2021 at 1:51 PM Olle Härstedt wrote: > > 2021-04-25 21:25 GMT+02:00, Larry Garfield : > > Greetings, Internalians! > > > > I would like to offer for your consideration another RFC, specifically > > syntax for partial function application. > > > >

Re: [PHP-DEV] [RFC] Partial function application

> If this is indeed the scenario, would it be worth adding a syntax to > indicate _all_ parameters can be placeholders? When a signature has > multiple arguments, `toString(?, ?, ?, ?)` could become `toString(...?)` or > maybe something like `toString(*)`? At the moment, there isn't any

Re: [PHP-DEV] [RFC] Partial function application

On Sun, Apr 25, 2021 at 3:08 PM Max Semenik wrote: > > On Sun, Apr 25, 2021 at 10:26 PM Larry Garfield > wrote: > > > https://wiki.php.net/rfc/partial_function_application > > > Amazing, I've wanted this for so long! Have you considered extending this > syntax to OOP, e.g. $obj->method(?) or

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei wrote: > > On Sat, Apr 24, 2021 at 2:56 PM Pierre wrote: > > > Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit : > > > Hello Internals, > > > > > > I'm sending this email to open discussion about sealed classes, > > > interfaces, and traits

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

On Sun, Apr 4, 2021 at 8:11 PM €– ”k”k wrote: > > Hello everyone. > > Direct execution opcode file without php source code file RFC vote is now > open. > > https://wiki.php.net/rfc/direct-execution-opcode > > The deadline for voting is April 20. > > Regards > Chopin Xiao For those who want to

Re: [PHP-DEV] [VOTE] Object scoped RNG implementation

On Wed, Mar 31, 2021 at 10:39 PM Go Kudo wrote: > > Hello everyone. > > Object scoped RNG RFC vote is now open. > https://wiki.php.net/rfc/object_scope_prng > > The deadline for voting is April 15. > > Previous discussions can be viewed below. > > https://externals.io/message/112765 >

  1   2   >