Fwd: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24

-- Forwarded message - From: David CARLIER Date: Wed, 30 Apr 2025 at 06:20 Subject: Re: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24 To: youkidearitai Hi youkidearitai. I would be in favor on moving to *whatever *viable solution in the long run appears (e.g. being

Re: [PHP-DEV] PHP socket ethernet support - step 2

On Tue, 4 Mar 2025 at 22:34, Tim Düsterhus wrote: > Hi > > On 3/4/25 23:18, Gina P. Banyard wrote: > > Those two classes predate the Namespaces in bundled PHP extensions [1] > RFC, I do think adding a namespace is better. > > And we could also move the two classes into the new namespace and add >

Re: [PHP-DEV] PHP socket ethernet support - step 2

On Mon, 3 Mar 2025 at 21:21, Jakub Zelenka wrote: > Hi, > > >> I am working on the second pass of this feature and write here because of >> the legitimate concern regarding new classes to add. >> >> PR here >> > > For those that want to quickly see the

[PHP-DEV] PHP socket ethernet support - step 2

Hi, I am working on the second pass of this feature and write here because of the legitimate concern regarding new classes to add. PR here I agree also on adding a namespace on top (Sockets ?) and changing the class names. Note that after that I plan

Re: [PHP-DEV] ext/sockets: socket_getpeername/socket_getsockname BC

Ok fair enough, will revert it. Cheers. On Wed, 29 Jan 2025 at 12:04, Jakub Zelenka wrote: > > > > On Wed, Jan 29, 2025 at 4:22 AM David CARLIER wrote: >> >> Hi, >> >> Working on this PR #17440, I wanted to ask if the BC from these two calls >> wer

[PHP-DEV] ext/sockets: socket_getpeername/socket_getsockname BC

Hi, Working on this PR #17440 , I wanted to ask if the BC from these two calls were ok because : Before function socket_getsockname(Socket $socket, &$address, *&$port = null*): bool {} After function socket_getsockname(Socket $socket, &$address, *?int

Re: [PHP-DEV] [RFC] Change Directory class to behave like an opaque object

Seems right thing to do. I saw some usage like final class Dir extends Directory { } also did not see much in *new* codes Directory being extended so 8.5 sure. Cheers. On Sat, 14 Sept 2024 at 16:36, Gina P. Banyard wrote: > Hello internals, > > I came across the Directory class while doing s

Re: [PHP-DEV] strrchr with needle with multiple characters

Hi, On Mon, 2 Sept 2024 at 12:20, Vincent Langlet wrote: > I was today old when I discovered the big difference between strchr and > strrchr in the way they handle needle with multiple characters. > > It's explained in the doc > https://www.php.net/manual/en/function.strrchr.php > - If needle co

Re: [PHP-DEV] ext/gd adding imagecompare

Hi On Tue, 9 Jul 2024 at 19:16, Tim Düsterhus wrote: > Hi > > On 7/9/24 19:53, David CARLIER wrote: > > Agreed, I ll likely just commit as is sometime this week. > > I hereby formally claim that this is not a simple self-contained > feature. It does require an RFC. &g

Re: [PHP-DEV] ext/gd adding imagecompare

On Tue, 9 Jul 2024 at 18:31, Saki Takamachi wrote: > Hi David, > > It seems to be the opposite regarding his proposition gdImageCompare(im1, > im2) & GD_CMP_IMAGE. Then yes you are right, we are losing the specifics. > If you want to figure out how the image 1 and image 2

Re: [PHP-DEV] ext/gd adding imagecompare

Hi, On Tue, 9 Jul 2024 at 17:59, Kamil Tekiela wrote: > Boolean is a much more confusing value here. A bit mask is ok, but I would > prefer a better solution. Maybe a simple value object? > That could be an option too sure.

Re: [PHP-DEV] ext/gd adding imagecompare

Hi Saki. On Tue, 9 Jul 2024 at 17:49, Saki Takamachi wrote: > Hi David, > > > Hi, > > > > I plan to add imagecompare to the gd extension. No problem so far > however a little discussion of the returned value > > > > https://github.com/php/php-src/pull/

[PHP-DEV] ext/gd adding imagecompare

Hi, I plan to add imagecompare to the gd extension . No problem so far however a little discussion of the returned value https://github.com/php/php-src/pull/14877#issuecomment-2217686123 I personally see a value of a bitmask rather than just boolean whi

[PHP-DEV] pcntl_exec update proposal

Hi, Through this existing PR , I wanted to know how would appeal to you adding some access restriction upon this existing call, using the open basedir check. So if the sysadmin wants the php user having no business calling `/bin` commands for examples wou

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 9:27 PM Michael Morris wrote: > > Near universal unity?? You're forgetting Wordpress, which has massive PHP > market share (more than 50% of PHP backed websites - well more than > depending on which survey you cite) and DOES NOT USE COMPOSER. And it DOES > NOT USE PSR-4 e

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 4:33 AM Michael Morris wrote: > Hello all. This is a ramble of an idea that's managed to run around my > head for a few days now. It isn't fully formed, but I've ran the thought > experiment as far as I can on my own and want to share it with all of you. > > If you got thi

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

On Wed, 19 Jun 2024, 09:31 Robert Landers, wrote: > > The problem isn't so much this, but in that it has become a dogma to > "have working types" and trying to explain why they do or do not > need/want it in the current context becomes a hopeless argument > because you are attacking their world-v

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

On Tue, 18 Jun 2024, 17:40 Robert Landers, wrote: > Hello internals, > > Many, many people start their files fairly religiously: > > > and I say "religiously" because from talking to people in real life, > reddit, workplaces, etc, very few php programmers actually know what > this does but do it

Re: [PHP-DEV] Bumping minimum PostgreSQL version to 10.0

Hi, I m all for the changes this update should not preclude any 10.0 client to connect to a 9.x server. cheers.

[PHP-DEV] gd heif support

Hi, I m trying to address an old ticket regarding HEIF support for gd. Here the PR One of the last bit concerns the imagecreatefromstring support part where I would need a custom stream handler for this format. Would you mind adding a dependency like it

Re: [PHP-DEV] ext/pgsql: pg_put_line deprecation proposal

Hi Matteo, On Mon, 20 May 2024 at 14:08, Matteo Beccati wrote: > Hi, > > Il 20/05/2024 14:03, David CARLIER ha scritto: > > I would like to know if it would be fine to deprecate pg_put_line > > <http://pg_put_line>. > > > > Reasoning is PQPutLine is part

[PHP-DEV] ext/pgsql: pg_put_line deprecation proposal

I would like to know if it would be fine to deprecate pg_put_line. Reasoning is PQPutLine is part of the obsolete list of calls for COPY purpose since the PostgreSQL protocol 3.0 version (supported since postgresql 7.4 relea

Re: [PHP-DEV] Requiring GPG Commit Signing

No problem with this, I apply this since couple of days. Cheers. On Tue, 2 Apr 2024 at 15:37, Jakub Zelenka wrote: > On Tue, Apr 2, 2024 at 3:36 PM Jakub Zelenka wrote: > >> On Tue, Apr 2, 2024 at 3:17 PM Derick Rethans wrote: >> >>> Hi, >>> >>> What do y'all think about requiring GPG signed

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

I second this, I think it is a good addition which makes a lot of sense. Cheers. On Mon, 25 Mar 2024 at 20:36, Ayesh Karunaratne wrote: > > > > 2024年3月9日(土) 15:26 youkidearitai : > > > > > > Hello, Internals > > > > > > I created an wiki for `grapheme_str_split` function. > > > Please see: > >

Re: [PHP-DEV] Filesystem path APIs

On Fri, 8 Dec 2023 at 16:10, Niels Dossche wrote: > Hi David > > On 08/12/2023 10:08, David CARLIER wrote: > > I think these would be great additions to PHP as working with paths > and files is a core part of any programming language. > > > > > > Seems

Re: [PHP-DEV] Filesystem path APIs

Hi Niels, On Wed, 6 Dec 2023 at 19:20, Niels Dossche wrote: > Hi internals > > I'd like to start a pre-RFC discussion about filesystem path APIs in PHP. > The reason I bring this up is because of this recent feature request: > https://github.com/php/php-src/issues/11258 > > The feature request i

Re: [PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

On Wed, Nov 29, 2023 at 7:19 AM Stephen Reay wrote: > So no, I don't think compact() should be deprecated, what I think *should* > happen, is to promote the current warning on undefined variables, to an > error, as per https://wiki.php.net/rfc/undefined_variable_error_promotion. > Whether this is

Re: [PHP-DEV] RFC Proposal - static modifier for classes

k there'd need to be some persuasively more substantial gain for either the developer or the execution of a script for this proposal to be worth anything. Thanks. -David

Re: [PHP-DEV] Array functions with strict comparison

On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings wrote: > So to me, this alone is an argument to implement this natively. > The other argument is that it is kind of sad how the current functions > don't behave as one would expect. I'd expect there to be a larger and proportionately increasing p

Re: [PHP-DEV] Array functions with strict comparison

On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings wrote: > Hello internals, > I noticed that array functions like array_diff(), array_intersect() > etc use weak comparison. > > That's not quite correct. Using the example of array_diff, the comparison is a strict equality check on a string cast of

Re: [PHP-DEV] [Discussion] Variable Type Declaration Before Usage

On Sun, Nov 5, 2023 at 1:37 PM Oladoyinbo Vincent wrote: > Hello Internals, > > I was wondering if php could introduce this feature or if any experienced C > dev here can work on the implementation of this feature. > > I think this is a much bigger issue than bikeshedding over syntax. The idea of

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

PHP lacks two very basic functions for working with arrays: - array_first() returning the first element of an array (or null) - array_last() returning the last element of the array (or null) While PHP has functions that return the first and last keys, array_key_first() and array_key_last(), it do

[PHP-DEV] Better name for method Randomizer::nextFloat()

I would like to suggest changing the name or removing the nextFloat() method, which is coming to PHP 8.3. The Random\Randomizer class will have two new methods for generating random numbers: - getFloat($min, $max [, $boundary]) - nextFloat() Now please try to guess what these methods do and, more

[PHP-DEV] Better name for method Randomizer::nextFloat()

I would like to suggest changing the name or removing the nextFloat() method, which is coming to PHP 8.3. The Random\Randomizer class will have two new methods for generating random numbers: - getFloat($min, $max [, $boundary]) - nextFloat() Now please try to guess what these methods do and, more

Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP

On Fri, Sep 8, 2023 at 2:12 PM Lanre Waju wrote: > Dear PHP Internals, > > I am writing to propose a new feature for PHP that introduces the > concept of structs. This feature aims to provide a more concise and > expressive way to define and work with immutable data structures. Below > is a detai

Re: [PHP-DEV] New reflection methods for working with attributes

What's the difference between this and what was proposed in https://externals.io/message/120799 ? I don't get why this wouldn't require an RFC.

Re: [PHP-DEV] Security implications of parsing env variables in .ini

On Fri, Jul 14, 2023 at 3:08 AM Dusk wrote: > 2) These expansions should probably be disabled by INI_SCANNER_RAW; that > flag already disables certain other types of value interpolation. (Oddly, > it doesn't disable expansion of constants either; that might be worth > revisiting as well.) Envir

Re: [PHP-DEV] Security implications of parsing env variables in .ini

On Thu, Jul 13, 2023 at 10:25 PM Sergii Shymko wrote: > For instance, functions parse_ini_string() and parse_ini_file() do support > the aforementioned env variables syntax, because the underlying code is > reused. That means that these functions can potentially be exploited to > read sensitive i

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

On Wed, Jul 12, 2023 at 5:01 AM G. P. B. wrote: > > Maybe the resistance to the proposal would be far less if the RFC, and > implementation, would check at compile time that the default > implementations only rely on known existing functions available to the > interface. > I asked in the discuss

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

Looks - sadly to me - like this isn't going to pass. I don't have vote karma and if I did it wouldn't make a difference to the outcome, but it would be really good for those of us who can't vote on the feature to hear from some of the people who voted against it why they chose no. The feedback from

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

On Tue, Jul 4, 2023 at 8:30 PM Nuno Maduro wrote: > Hi Internals, > > I am writing to request karma privileges to vote on PHP RFCs. > > I'm not a voter and have no influence here but from previous discussions which have come from similar requests, I don't think you're likely to get this. The conv

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

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 language features for a long time - but I think this > is > > an issue with the proposed implementation which at the very least > warrants > > hig

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

On Mon, Jun 19, 2023 at 9:53 PM Rowan Tommins wrote: > On 19/06/2023 20:20, David Gebler wrote: > > Okay, thanks. That's really quite significant, since it changes the > feature > > to one which could allow changes made to interfaces to adversely impact > > exi

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

On Mon, Jun 19, 2023 at 3:53 AM Levi Morrison wrote: > > No, there's no attempt to ensure the method body adheres to calling > the public interface. Due to PHP's possible dynamic behaviors, I don't > think it's reasonable to attempt to enforce it at compile-time. I'm > not sure it's worth the eff

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

On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals < internals@lists.php.net> wrote: > > I am moving my RFC for interface default methods to discussion: > https://wiki.php.net/rfc/interface-default-methods. > > Can I ask, the RFC doesn't say - does your implementation ensure default imple

Re: [PHP-DEV] RFC [Concept] - Interface Properties

descending into a philosophical wayside about principles of programming and "best practices". And my views on those things are probably quite anodyne, but the margin for difference in good opinions is more than enough that I don't want to go there. -Dave On Sun, May 28, 2023 at 5:03 PM

Re: [PHP-DEV] RFC [Concept] - Interface Properties

On Sun, May 28, 2023 at 10:33 AM Rowan Tommins wrote: > I don't follow. If a property is public, then code outside the class can > rely on being able to access it. That seems to me to be a contract between > the class and its users, not an implementation detail - e.g. removing the > property, or

Re: [PHP-DEV] RFC [Concept] - Interface Properties

On Sat, May 27, 2023 at 9:44 PM Zoltán Fekete wrote: > Abstract class could help this but it’s like using a > tube wrench for a nut. Also one class can extend only one abstract class. > By > simply defining interfaces with properties would save a lot of boilerplate > code > and there would be no

Re: [PHP-DEV] RFC [Concept] - Interface Properties

On Sat, May 27, 2023 at 6:24 PM Larry Garfield wrote: > On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote: > > Hello internals, > > > > Based on a few discussions I've had recently, my team and I couldn't > > think of any reason why we shouldn't have properties on interfaces as > > I wouldn'

Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])

On Tue, May 23, 2023 at 9:27 PM Tim Düsterhus wrote: > Just to make sure there is no misunderstanding I'd like to clarify that > the proposed check of this RFC is not a runtime error. It's a compile > time error, just like the check for incompatible method signatures > during inheritance. In fact

Re: [PHP-DEV] rounding integers

On Sun, May 21, 2023 at 4:21 PM Larry Garfield wrote: > > Having recently been bitten by floor() returning a float even though the > value that comes back is logically an int, I would be fully in support of > "and returns an int" versions of these functions in core. > What about adding a third,

Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])

On Mon, May 22, 2023 at 1:01 PM Dan Ackroyd wrote: > Even for those who use static analysis, most (afaik) don't have it > running constantly in local development and this RFC would prevent > people wondering why their code is behaving surprisingly before it is > static analysed. > It takes care

Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])

On Thu, May 18, 2023 at 9:12 AM Marco Pivetta wrote: > > Would it perhaps make sense to have this in userland first, in phpstan or > psalm plugins, to see if there is interest? > 100% this in my view; this is exactly the kind of check which you would expect to be done at the static analysis stag

Re: [PHP-DEV] [RFC] path_join function

On Wed, May 17, 2023 at 4:31 PM Chase Peeler wrote: > Definitely a useful feature, but not sure it needs to be a core function. > > I feel the same. There are countless useful utility functions which could exist in core, many of which are even widely used and commonly reinvented as userland funct

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

On Thu, Apr 20, 2023 at 6:25 PM Larry Garfield wrote: > ## The options > > There's three ways we've come up with that this design could be > implemented. In concept they're not mutually exclusive, so we could do > one, two, or three of these. Figuring out which approach would get the > most sup

Re: [PHP-DEV] How to deal with bugs in vendored libraries?

t with you, Max, through your PR too. If you could be more diplomatic and improve on that, that would be awesome. David C. Cheers.

Re: [PHP-DEV] base64url format

On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans wrote: > On 9 January 2023 18:49:28 GMT, Sara Golemon wrote: > >I've been working with JWTs lately and that means working with Base64URL > >format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 ) > >This is essentially the same thing as norm

Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index

On Mon, Dec 12, 2022 at 10:20 PM Dan Liebner wrote: > As the RFC points out, "Some languages, such as JavaScript, do not consider > accesses to undefined array keys to be an error condition at all, and allow > such an operation to be performed silently." > It is by definition an error condition

Re: [PHP-DEV] Compact can't resolve outer scoped variables using short closures

t;function", and getting back to the main topic, would it be possible to do the same with compact()? fn() => compact('dummy') turns into: fn() => [ 'dummy' => $dummy ] which turns into: function() use($dummy) { return [ 'dummy' => $dummy ]; } Atenciosamente, David Rodrigues

Re: [PHP-DEV] Compact can't resolve outer scoped variables using short closures

ectly over the resulting array, rather than the compact itself. Atenciosamente, David Rodrigues Em qua., 19 de out. de 2022 às 14:09, Marco Pivetta escreveu: > On Wed, 19 Oct 2022, 19:04 David Rodrigues, > wrote: > >> Hello! >> >> I'm converting my code to u

[PHP-DEV] Compact can't resolve outer scoped variables using short closures

ssibility of this being fixed? I would love to help, but I don't have much C programming skills, unfortunately. Atenciosamente, David Rodrigues

Re: [PHP-DEV] [RFC] Destructuring Coalesce

#x27;123' [ $a ?: '123' ] = [ 456 ]; so $a = 456 Atenciosamente, David Rodrigues

Re: [PHP-DEV] Feature preview (formely was: experimental features)

>From what I understand, your concern is "what if we need to change the direction of something already decided"? For example, initially it was decided and very well accepted private(set), but after a while the idea was revised and it was decided that private:set would be better instead. In this ca

Re: [PHP-DEV] Feature preview (formely was: experimental features)

taxes to co-exist in this feature is acceptable (which I personally think is a bad idea). Atenciosamente, David Rodrigues Em ter., 11 de out. de 2022 às 22:23, Larry Garfield escreveu: > On Tue, Oct 11, 2022, at 3:25 PM, David Rodrigues wrote: > > In order to try to organize a litt

[PHP-DEV] Feature preview (formely was: experimental features)

eatures should generally be released in patch versions (eg. PHP 8.1.12 to preview a PHP 8.2 feature). Atenciosamente, David Rodrigues

Re: [PHP-DEV] Experimental features

On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues wrote: > The idea is that the experimental features are exclusively something that > the PHP team has voted for (approved) and that will be part of the language. > So they're not experimental features, they're accepted RFCs,

Re: [PHP-DEV] Experimental features

use experimental_json_validate(), else use previous PHP compatible code. Atenciosamente, David Rodrigues Em seg., 10 de out. de 2022 às 19:20, David Gebler escreveu: > My two cents... > > Why can't "common users" install a PECL extension? It's not a difficult, &

Re: [PHP-DEV] Experimental features

My two cents... Why can't "common users" install a PECL extension? It's not a difficult, obscure or undocumented process. I can accept the reasoning > Apply a PECL strategy to try experimental features might not be the convenient way always, for example, if we create a new ... sensitive ini sett

Re: [PHP-DEV] Experimental features

earlier feedback from users willing to test it. Atenciosamente, David Rodrigues Em qui., 6 de out. de 2022 às 17:12, Rowan Tommins escreveu: > On 06/10/2022 17:41, Alex Wells wrote: > > For example, Kotlin has recently introduced a new feature - unsigned > integer types. > > &g

Re: [PHP-DEV] Sanitize filters

On Tue, Oct 4, 2022 at 11:34 AM Rowan Tommins wrote: > The "notorious" thing I know is that validating e-mail addresses is next > to impossible because of multiple overlapping standards, and a huge > number of esoteric variations that might or might not actually be > deliverable in practice. If y

Re: [PHP-DEV] Experimental features

atures and shouldn't be used in production (unless you're willing to take risks). The difference between using the in-development version of PHP 8.2 is that many servers only make this version officially available after a few months, while smaller versions of PHP usually become available w

Re: [PHP-DEV] Experimental features

are available natively and enabled by default, it would be interesting, because it would be easier to separate the main code from the code in development/refinement (and that can be rejected at some point in a more practical way, and maybe be kept as just an extension apart from PHP). Atencios

[PHP-DEV] Experimental features

before the next version is released, allowing users to try them out more easily. Atenciosamente, David Rodrigues

Re: [PHP-DEV] Sanitize filters

On Mon, Oct 3, 2022 at 11:29 AM Max Semenik wrote: > > Is there a compelling need to have this in the core, as opposed to > Composer packages? The ecosystem has changed a lot since the original > function was introduced. > I don't know that there is, I suspect the answer is probably not and sani

Re: [PHP-DEV] Sanitize filters

On Sun, Oct 2, 2022 at 4:10 PM Larry Garfield wrote: > The filter extension has always been a stillborn mess. Its API is an > absolute disaster and, as you note, its functionality is unclear at best, > misleading at worst. Frankly it's worse than SPL. > > I'd be entirely on board with jettisoni

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

On Sat, Sep 10, 2022 at 3:05 PM juan carlos morales < dev.juan.mora...@gmail.com> wrote: > I also agree that increasing the size to something bigger than 8M > might not be a good idea; I can imagine that a value bigger than 8M > (like 50M) will cause an impact in hosting platforms specially, which

Re: [PHP-DEV] Re: Increase maximum size of an uploaded file to 50Mbyte

On Wed, Sep 7, 2022 at 10:47 PM Kris Craig wrote: > On Wed, Sep 7, 2022 at 11:38 AM juan carlos morales < > dev.juan.mora...@gmail.com> wrote: > > > I looked for a potential problem out of doing such a change but I could > not > > find anything. > > > > Then I'd say it's a no-brainer. The curren

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

Juan, You can always offer two votes on the RFC - one for the function itself, then one for should it return boolean or return an int representing the json_last_error constants and let it be decided that way. I think on the whole, I agree with the sentiment that returning boolean and checking json

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

On Fri, Aug 26, 2022 at 6:29 PM Kamil Tekiela wrote: > What is the reasoning behind the name? I can't find it explained in the > RFC. What about other alternatives like is_json or validate_json? > The name json_validate makes most sense to me; it groups itself together nicely with the other json

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

Having actually compiled the branch and tried it out, I have to say regardless of whether validating arbitrarily large blocks of JSON without being interested in the contents is a common or more niche use case, the memory savings ARE highly impressive. I had thought that because the function was bu

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

I'm not a voter on RFCs so my input may be largely irrelevant here but for discussion purposes: I remain unconvinced regarding the justification for this proposal. I'm not saying there's a strong reason to NOT implement it, but I'm not convinced it's really going to be a significant benefit to man

Re: [PHP-DEV] Proposal for floored division and modulo functions

On Tue, Aug 23, 2022 at 6:27 PM Daniel Wolfe wrote: > > If we do go down the operator route, however, what tokens should be > chosen? `%%` makes since for floor modulo, but `//` is already used for > comments. > Yeah I appreciate it is tricky, because // is pretty much the only obviously sensibl

Re: [PHP-DEV] Proposal for floored division and modulo functions

On Mon, Aug 22, 2022 at 4:22 AM Daniel Wolfe wrote: > For the first four instances, the function works as intended since the > timestamps are non-negative numbers. However, for the fifth example, > since the date is before 1970, the timestamp is going to be negative > resulting in an ostensible a

Re: [PHP-DEV] array_merge() vs array unpacking performance

han array unpacking. Atenciosamente, David Rodrigues Em seg., 1 de ago. de 2022 às 14:45, Kamil Tekiela escreveu: > Hi David, > > It would be useful if you could provide your measurements and the way you > arrived at such results. A quick test doesn't seem to support your > fin

Re: [PHP-DEV] RFC Idea - is_json - looking for feedback

On Sun, Jul 31, 2022 at 4:41 PM Larry Garfield wrote: > So the core argument, it seems, is "there's lots of user-space > implementations already, hence demand, and it would be > better/faster/stronger/we-have-the-technology to do it in C." > There's innumerable features implemented in userland w

[PHP-DEV] array_merge() vs array unpacking performance

Hello! PHP 8.1 supports array unpacking with keys. I guess that is very similar to array_merge(), but for some reason array_merge() is 50% slower than unpacking. So my question is: is there some way to optimize the engine so array_merge() can work like unpacking? Thanks!

Re: [PHP-DEV] RFC Idea - is_json - looking for feedback

On Sat, Jul 30, 2022 at 3:01 PM Nikita Popov wrote: > On Fri, Jul 29, 2022 at 4:27 PM juan carlos morales < > dev.juan.mora...@gmail.com> wrote: > > > I am following the RFC guideline for the first time. ( > > https://wiki.php.net/rfc/howto) > > > > As suggested there, I am here to get a feeling

Re: [PHP-DEV] RFC Idea - is_json - looking for feedback

ntion. The performance would also be absurdly better. What worries me above is the misuse of the function, like checking if is_json() === true and using json_decode() right after. However, I believe this can be easily optimized by the engine itself. My vote is YES. Atenciosamente, David Rodrigues

Re: [PHP-DEV] Adding new closing tag =?> for keeping trailing newline

On Sun, Jun 5, 2022 at 9:24 AM shinji igarashi wrote: > Hello everyone, > > I'd like to propose adding a new closing tag `=?>` to the language. > > PHP currently removes the newline character immediately following > the closing tag `?>`. > Personal opinion, seems like a classic sledgehammer on a

[PHP-DEV] VCS Account Request: devnexen

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

Re: [PHP-DEV] Early feedback on encrypted session PR

Thanks all for the early feedback. So it is an attempt to mitigate tampering attacks basically on session stored on filesystems. So it appears to be a subset of session usage overall indeed but doing so in a native manner is what drove the PR. On Wed, 18 May 2022 at 18:43, Christoph M. Becker wr

[PHP-DEV] Early feedback on encrypted session PR

Hi, I wanted a more general but early feedback on the idea itself https://github.com/php/php-src/pull/3759 which is encrypting/decrypting the session on the fly with openssl (assuming as an improvement it would need a more complex key than the session id to make it more useful and being configura

Re: [PHP-DEV] [RFC] Undefined Property Error Promotion

> $foo[?'maynotexist'] // returns null and emits no warning In JS we have some like: foo['maynotexist'] foo?.['maynotexist'] In PHP could be: $foo['maynotexist'] $foo?->['maynotexist'] Atenciosamente, David Rodrigues Em sex., 15 de ab

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

Maybe I'm a little late to this discussion, but is there any reason why *false|null* is allowed but *true|null* is not? I can think of few cases where *true|null* could be interesting, but I've been through situations like this. Atenciosamente, David Rodrigues Em sáb., 12 de mar.

Re: [PHP-DEV] RFC: Trait expects interface

#x27;, $message); } } in the manner of Java...no idea how easy or not it would be for someone a little more experienced than me working on PHP core to do this though. - David > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >

Re: [PHP-DEV] RFC: Trait expects interface

#x27;s my two cents, good luck with whatever you're trying to do anyway. - David > -- > Kirill Nesmeyanov

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

On Mon, Jan 3, 2022 at 5:38 PM Nikita Popov wrote: > On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux > wrote: > > > Hello internals, > > > > I've opened voting on > > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting > will > > close on 2022-01-17. > > > > To review past discussi

Re: [PHP-DEV] header() allows arbitrary status codes

On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker wrote: > Hi all, > > a while ago it has been reported[1] that our header() function actually > allows arbitrary status codes, which may even overflow. Of course, that > makes no sense, since the status code is supposed to be a three digit > cod

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

Ahhh okay that explains where this change is coming from. Thanks a lot, Dan! I wonder if this side effect ("all dependencies are iterated also during "make install") is intentional. Maybe Niki can chime in on GitHub; I'll ping him there, as well as the original author. Thank

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

REFIX directory that, in its entirety, can be compressed into an archive for distribution of only that extension's files. Does that make sense? On Thu, Dec 9, 2021 at 8:28 PM Dan Ackroyd wrote: > > On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals > wrote: > > > >

  1   2   3   4   5   6   7   8   9   10   >