Re: [PHP-DEV] Proposal: Support for RFC4648 in PHP

Hi Ignace, I fully support the idea, and I also share the opinion that PHP should evolve by improving its standard library from the mostly procedural APIs consisting of functions here and there to "cleaner", more organized and consistent object oriented APIs. I also agree that performance sensitiv

Re: [PHP-DEV] [RFC] [Vote] Add WHATWG compliant URL parsing API

Hello Internals, The "Add RFC 3986 and WHATWG URL compliant API" RFC ( https://wiki.php.net/rfc/url_parsing_api) has just been accepted with 30 "yes" and 1 "no" votes. Regards, Máté

[PHP-DEV] [RFC] [Vote] Add WHATWG compliant URL parsing API

Hello Everyone, As promised a few days ago, I hereby start the vote for the "Add RFC 3986 and WHATWG URL compliant API" RFC. The vote will be open until 2025-05-22. RFC link: https://wiki.php.net/rfc/url_parsing_api Discussion thread: https://externals.io/message/123997 Regards, Máté

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hello Internals, After more than a hundred emails refining even the tiniest details, we have reached a point where I'd like to call for a vote. I know that the new API still doesn't support many use-cases, it still has missing pieces, but now it includes a cohesive set of functionality that could

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Paul, I would not presume that the dedicated value objects are what "makes the > [Rowbot] library much slower" than the RFC -- instead, my first intuition is that the *parsing* operations are slower in userland > than in C, and are primarily responsible for the comparative slowness. Speedwise

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hey Ignace, > I see you updated the RFC but I believe there's still some errors in the > example: > $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws > Uri\WhatWg\InvalidUrlException because of $baseUri > After following the suggestion of Tim, I changed the type of the $baseUrl parameters

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, Why can't the Url::resolve method also expose the `$errors` parameter like > the constructor and the parse static method ? As far as I understand it > nothing prevents the API from exposing the errors during URI resolution > which is a proxy method for the constructor call just like the

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, I have just added the SensitiveParameter attribute to the Uri\Rfc3986\Uri::withUserInfo() and Uri\WhatWg\Url::withPassword() methods. > Reading the WHATWG URL specification and checking how > >- Chrome, >- Firefox >- and even https://github.com/TRowbotham/URL-Parser > > >

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, The $excludeFragment is `true` by default so in the example it should be > `false` instead. Perhaps using an Enum instead would make the > DX easier than using a boolean ? > I believe the same issue is in all examples regarding the use of that > parameter. > You are right, I completely

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, > In https://news-web.php.net/php.internals/127114 I suggest to only > provide the "non-raw" methods, so I believe you misread that. I've just > given the RFC another read and thought about the naming and I believe I > still prefer not having the "raw" in the name: > > - Having the `raw`

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > Currently the path is nullable but according to the RFC the path can not > be nullable > According to the RFC the path can have up to 5 ABNF representation > Uh, this is something that I also forgot to sync between the implementation and the RFC. I also recently found out that the g

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > Uh, this is something that I also forgot to sync between the > implementation and the RFC. I also recently found out that > the get*Path() methods should be non-nullable for both classes, so I > recently fixed them. Sorry for the confusion! > Actually, I realized after checking the

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi, Tim Düsterhus ezt írta (időpont: 2025. ápr. 17., Cs, 9:22): > Hi > > Am 2025-04-15 23:55, schrieb Máté Kocsis: > > This was one of my (unspoken) ideas as well. I used to think there must > > have been a correct logic > > for percent-decoding of WHATWG compon

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, > Perhaps the correct solution would be to offer only the non-raw methods > for WHATWG URL and to not attempt any additional percent-decoding there? > My reasoning is that the WHATWG URL is a living standard anyways, so > trying to add additional semantics on top will result in sadness. M

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, I think I would prefer: > > namespace Uri { > class InvalidUriException extends \Uri\UriException > { > } > } > > namespace Uri\WhatWg { > class InvalidUrlException extends \Uri\InvalidUriException { > /** @var list */ >

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hey Ignace, (let me answer in the original thread, as apparently the discussion continued in a separate thread from the main one) > - I believe during normalization of IPv6 host the letter a-f should be > lowercase in accordance with the RFC since > > RFC3986 follows https://www.rfc-editor.org/rf

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, it might be brought back for future improvements. > > Yes, surely! > I have one last question regarding the URI implementations which are raised > by my polyfill: > > Did you also took into account the delimiters when submitting data via the > withers ? In other words is > > ```php

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > I spotted another inconsistency in the normalization under RFC3986 > Thanks for spotting this: apparently, it is due to a small bug in the uriparser library, which I managed to fix locally, PR is on its way to upstream. Máté

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > upon further inspection and verification of RFC3986 I also see an issue > with the example used for normalization in the RFC. According to RFC3986 ( > https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) : > > The reg-name syntax allows percent-encoded octets in order to >

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Larry and everyone who took part in the final vs non-final debate, Thought: make the class non-final, but all of the defined methods final, > and any internal data properties private. That way we know that a child > class cannot break any of the existing guarantees, but can still add > conveni

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, While implementing the polyfill I am finding easier DX wise to make the > constructor private and use instead named constructors for instantiation. I > would be in favor of > > `Uri::parse` and `Uri::tryParse` like it is done currently with Enum and > the `from` and `tryfrom` named cons

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Dennis, I am myself also a bit lost on the countless names that I tried out in the > implementation, but I think I had toHumanFriendlyString() and > toDisplayFriendlyString() methods at some point. These then ended up being > toString() and toDisplayString() after some iterations. I would be ok

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Paul, ## Rowbot > > (None of the classes are readonly or final; these look to hew closely to > the WHATWG-URL spec.) > > A BasicURLParser class: > > - affords relative parsing capability and an option parameter for the > target URLRecord > - returns a URLRecord > > A URLRecord class: > > - publ

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Paul, > If we want a full-featured WHATWG-URL implementation in core, would it not > be preferable (with Trevor's permission) to convert rowbot/url from > userland to core instead? Surely conversion from an existing, well-tested, > widely-used implementation would be easier/better/faster than

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, 1) around `Uri\UninitializedUriException` If I look at the behaviour of > `DatetimeImmutable` in the same scenario or a Userland object instead of > throwing an exception an error is thrown > > see: > > - https://3v4l.org/d4VrY > - https://3v4l.org/Wn7En > > Shouldn't the URI feature fo

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Dennis, > This is a late thought, and surely amenable to a later RFC, but I was > thinking about the get/set path methods and the issue of the / and %2F. > > - If we exposed `getPathIterator()` or `getPathSegments()` could we not > report these in their fully-decoded forms? That is, because t

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi, Depends on there being the intention to have it as parameter type. If it's > designed to be passed around to functions I really don't want it to be an > array. I am maintaining a legacy codebase where arrays are being used as > hashmaps pretty much everywhere, and it's error prone. We lose all

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Nicolas, For now, let me just quickly respond to your question regarding __debugInfo(): The RFC is also missing whether __debugInfo returns raw or non-raw > components. Then, I'm wondering if we need this per-component break for > debugging at all? It might be less confusing (on this encoding

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, > > All URI components - with the exception of the host - can be > retrieved in two formats: > > I believe you mean - with the excepotion of the Port > > Even though I specifically meant WHATWG's host that is only available in only one format, you are right, the port is never availabl

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Hammed, What's wrong with declaring all the methods as final eg. > https://github.com/lnear-dev/ada-url/blob/main/ada_url.stub.php I've just noticed your message, sorry. Coincidentally - as I wrote a few days ago -, I'm also experimenting with making methods final. Máté >

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, > The same is true for `UriOperationException`. The RFC says that it can > happen for memory issues. Can this actually happen? My understanding is > that the engine bails out when an allocation fails. In any case if a > more graceful handling is desired it should be some generic > `OutOfM

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Juris and Tim, > Am 2025-02-23 18:47, schrieb Juris Evertovskis: > > As those are URI validation errors, maybe something like > > `Uri\WhatWg\ValidationError` would be both less clashy and less > > redundant? > > I like that suggestion. > > Best regards > Tim Düsterhus > I liked it as well, s

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Gina, 1. > The paragraph in at the beginning of the RFC in the > Relevant URI > specifications > WHATWG URL section seems to be incomplete. > Hopefully it's good now. Although I know this section doesn't include much information. 2. > I don't really understand how the UninitializedUriExceptio

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, Thank you again for the thorough review! > The naming of these methods seems to be a little inconsistent. It should > either be: > > ->getHostForDisplay() > ->toStringForDisplay() > > or > > ->getDisplayHost() > ->toDisplayString() > > but not a mix between both of t

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Dennis, > > I only harp on the WhatWG spec so much because for many people this will > be the only one they are aware of, if they are aware of any spec at all, > and this is a sizable vector of attack targeting servers from user-supplied > content. I’m curious to hear from folks here hat fracti

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, Thank you for your efforts! > Specifically for RFC3986Uri I see that the only difference between the > `parse` named constructor and the constructor is that the former will > return `null` instead of throwing an exception. But it is not clear if both > methods can work with partial UR

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Tim, Thanks for your feedback! > The RFC is not listed in the overview page: https://wiki.php.net/rfc Uh, indeed! I've just fixed it. > 2. > > I agree with Dennis' remark that the `Rfc3986Uri` and `WhatWgUri` > classes must be final. The RFC makes the argument that: > > > Having separate

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Larry, I do have concerns about the class design, though. Given the improvements > to the language, the accessor methods offer zero benefit at all. > Public-read properties (readonly or otherwise) would be faster and offer no > less of a guarantee. If you want to allow someone to extend the c

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Dennis, Even though I didn't answer for a long time, I was improving my RFC implementation in the meanwhile as well as evaluating your suggestions. I’m worried about the side-effects that having a global uri.default_handler could > have with code running differently for no apparent reason, or

[PHP-DEV] Real-time benchmark suite has just been added

Hi Everyone, It's been a while when I sent my email about introducing an automatic benchmark suite I had been working: https://externals.io/message/116323#116323 Now I would like to share an important milestone of this project: After doing lots of improvements and fixes throughout the year, the s

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, Niels, Sorry for being silent for so long, I was working hard on the implementation besides some summer activities :) I can say that I had really good progress in the last month and now I think (hope) that I managed to address most of the concerns/suggestions people mentioned in this th

Re: [PHP-DEV] [RFC] Decoding HTML and the Ambiguous Ampersand

Hi Christoph, Dennis, Well, I don't think it would be a big deal to move the bundled lexbor to > somewhere where it is always available. I mean, so far it's only used > by ext/dom so it's bundled there, but if other parts of the php-src code > base would use it, we could put it elsewhere. > Exac

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hey Ignace, Nicolas, Based on your request for adding support for RFC 3986 spec compatible parsing, I evaluated another library (https://github.com/uriparser/uriparser/) in the recent days in order to add support for the requested functionality. As far as I can tell, the results were very promisin

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Stephen, I agree with the others, the static parser class is weird. Either put the > static methods on the url class, or make the parser an instance with > options. > Yes, I was sure that many people would find the signature of the parser weird, and I can totally understand it. Since I don't h

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace, As far as I understand it, if this RFC were to pass as is it will model > PHP URLs to the WHATWG specification. While this specification is > getting a lot of traction lately I believe it will restrict URL usage in > PHP instead of making developer life easier. While PHP started as a >

Re: [PHP-DEV] [RFC]I'd like to see the RFCs that deprecate the FFI non-static approach start voting

I am the author of that "stupid" commit and RFC ( https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#fficast_ffinew_and_ffitype ) which you are referring to. I can understand that you are unhappy about the outcome of the RFC, but I would have happily incorporated your feedback

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Niels, First of all, thank you for your support! Why did you choose UrlParser to be a "static" class? Right now it's just a > fancy namespace. That's a good question, let me explain the reason: one of my major design goals was to make the UrlParser class to be extendable and configurable (e.

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> > It mirrors the interface, but it can’t be swapped out for a UriInterface > instance, especially since it can’t be extended, so I wouldn’t consider it > compatible. I would still need to write a compatibility layer that composes > Url\Url and implements UriInterface. > I guess my words were sli

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Larry, Thank you very much for your feedback! I think I have already partially answered some of your questions in my previous email to Niels, but let me answer your other questions below: * I... do not understand the point of having public properties AND > getters/withers. A readonly class wi

[PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Everyone, I've been working on a new RFC for a while now, and time has come to present it to a wider audience. Last year, I learnt that PHP doesn't have built-in support for parsing URLs according to any well established standards (RFC 1738 or the WHATWG URL living standard), since the parse_u

Re: [PHP-DEV] [RFC] [Vote] Add dedicated StreamBucket object

Hi Internals, The vote has been closed and unanimously accepted. Thanks to everyone who participated during the discussion and the vote! Regards, Máté

[PHP-DEV] [RFC] [Vote] Add dedicated StreamBucket object

Hi Everyone, As promised last week, I am opening the vote for the dedicated StreamBucket object RFC. RFC: https://wiki.php.net/rfc/dedicated_stream_bucket Discussion thread: https://externals.io/message/122190 The vote remains open until 2024-04-11 10:00 UTC. Regards, Máté

Re: [PHP-DEV] [RFC] Add dedicated StreamBucket object

Hey Nicolas, Sorry for the multi-months pause, I was working on other stuff recently. Thank you again for the insights! I'm not sure anyone besides you has ever used this property, but now we know about at least one use-case. :) That's why I slightly changed the proposal: the property would only

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

Hi Nicolas, Thanks for your input and proactive measures! I've just finished the analysis you asked for: - code: https://gist.github.com/kocsismate/c0d10c820606dfe297f09374aa634df5 - results: https://gist.github.com/kocsismate/cf3bdfbf35eb10224ee5ecd29b39656b TLDR: there are 880 packages out of 2

Re: [PHP-DEV] Re: [RFC] [Vote] Resource to object conversion

Hi Nicolas, - for curl - that's already supported by CurlHandle so this is seamless > - for DBA, because dba_list() works by > resourceid > - for resources created by stream_socket_server() and > stream_socket_accept() > > I only checked situations where the resource

Re: [PHP-DEV] [RFC] Add dedicated StreamBucket object

> What should users replace $bucket property with in PHP 8.4? Is there > an alternative or is this a deprecation without a way to solve it? If > there is currently no alternative I would not deprecate it. Just > remove it once it becomes useless. > Do users actually use the $bucket property? I wou

[PHP-DEV] [RFC] Add dedicated StreamBucket object

Hi Internals, As I have already shared my intentions in https://externals.io/message/122149, I'd like to add a dedicated object for stream buckets as opposed to the stdClass instances which are used nowadays. Please read https://wiki.php.net/rfc/dedicated_stream_bucket Regards, Máté

Re: [PHP-DEV] Dedicated StreamBucket class

Hi Jakub, > The only issue that I see that if you migrate the resource to object you > effectively drop that property which might be a BC break but based on the > recent RFC results it will happen in PHP 9.0 so it's not such a big issue. > I think this might be actually an opportunity to deprecat

[PHP-DEV] Re: [RFC] [Vote] Resource to object conversion

Hi Everyone, I've just closed the votes with the following outcomes: - The primary vote for the described approach for converting resources to objects was accepted unanimously (30 yes, 0 no) - Primary stream resources are going to be migrated in a major version, rather in any minor or major versio

Re: [PHP-DEV] Dedicated StreamBucket class

Hi Jakub, I just submitted feedback to the PR but will also mention it here as it's > probably more an API thing. The problem that I see is that it combines two > distinct things and create quite ugly self reference inside the proposed > StreamBucket object. I would prefer we split it and introduc

[PHP-DEV] Dedicated StreamBucket class

Hi Everyone, Recently, I realized that the stream_bucket_new() and stream_bucket_make_writeable() functions create stdClass instances by dynamically adding a "bucket", a "data" and a "datalen" property to it. A few days ago, I submitted a PR which makes the above mentioned functions return a dedi

Re: [PHP-DEV] [RFC] [Vote] Resource to object conversion

Hi Kamil, Good question... After the workaround, I think there's less reason to do the conversion in the next major version indeed. To be honest, I am not able to recall any use-case where a real BC break could happen. I mean, there is a very tiny one where resources can be casted to integers, whi

[PHP-DEV] [RFC] [Vote] Resource to object conversion

Hi Everyone, As mentioned a few days ago, I've just opened the vote about resource to object conversion. The vote will be open for 2 weeks. RFC link: https://wiki.php.net/rfc/resource_to_object_conversion Discussion thread: https://externals.io/message/121660 Regards, Máté

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

Hey Larry, That's fine for the main vote, but the others are all either/or votes, not > yes/no votes, so 2/3 majority doesn't mean anything. Do you mean those are > 50/50 votes, or something else? > Thanks for your insight again, You are right, it was a silly bug in the RFC. I've just fixed it s

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

Hi Everyone, If there are no further complaints, I intend to start the votes ( https://wiki.php.net/rfc/resource_to_object_conversion) the day after tomorrow. Regards, Máté

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

Hi Larry, Thanks for your input. I'm fine with adding a separate vote whether votes are ok with the described approaches of converting resources to objects, and then the 3 way vote can be eliminated. Regards, Máté

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

Hey Everyone, Sorry for the radio silence, I was busy with other tasks. However, I managed to improve the RFC in the recent days the following way: - most importantly, I changed the suggested approach of the conversion in case of primary stream resources: the is_resource() hack mentioned a few tim

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

Hi Derick, Jakub, Phiip > Did you do an analyses as to how much either of these changes could break > anything? I updated the RFC with some impact analysis. The numbers support my hypothesis that the conversion of auxiliary stream resources would cause hardly any BC break - at least in case of

[PHP-DEV] [RFC] [Discussion] Resource to object conversion

Hi Internals, Following my straw poll about the Process resource name, I would like to present an RFC which clarifies the rough timeline and the BC promises of the "resource to object conversion" project. Link: https://wiki.php.net/rfc/resource_to_object_conversion I'm looking forward to your fe

Re: [PHP-DEV] [STRAW POLL] [VOTE] Process resource to object migration

Hi Internals, The vote was closed, and thanks to Derick's calculations, we have a winner: ProcessHandle. Thanks to everyone who participated in the vote! I think we should have a proper vote if this should go to 8.4 at all. I > would vote against this due to the BC break. I would be fine with 9.

Re: [PHP-DEV] Change the signature of odbc_connect

Hi Saki, In my opinion, this is a simple and useful bugfix + nice consistency improvement with negligible backward compatibility break, so I don't think it needs any vote. Regards, Máté

Re: [PHP-DEV] [STRAW POLL] [VOTE] Process resource to object migration

Hi Tim, > > I assume this should read 2023-**11**-07? This would match the 14 days > for regular votes. > Yes, such a silly typo, thank you for pointing that out. The deadline is indeed in November. Regards, Máté

[PHP-DEV] [STRAW POLL] [VOTE] Process resource to object migration

As I have indicated in my last mail ( https://externals.io/message/121164#121364), I would like to decide the naming question of the "le_proc_open" resource via a straw poll. Therefore, I've just opened the vote: https://wiki.php.net/rfc/process_object_name It is a ranked choice poll (following ST

Re: [PHP-DEV] proc_open() resource to opaque object migration

Hi Tim, > I agree here. While I'm totally in favor of using namespaces in core, it > should be done somewhat consistently. If the proc_* functions are in the > global namespace, then so should the resource object. > While I don't necessarily want to add a dedicated namespace for Process (or what

[PHP-DEV] proc_open() resource to opaque object migration

Hi Everyone, I'm writing in connection with a question coming up lately during the "resource to opaque object migration" project ( https://github.com/php/php-tasks/issues/6) which we have been working on for quite a long while. During the review of my PR migrating the resource returned by proc_op

Re: [PHP-DEV] Arginfo Mismatch For Optional Parameters

Hi, The problem is that your arginfo declares parameters of type double, while you accept the double|null type in ZPP. P.s. i'm not sure based on your message whether you use stubs for declaring symbols, but if that's not the case, then doing so is highly recommended. You can find plenty of examp

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

Hi Everyone, The votes have ended with the following results: - array_keys: rejected (13 vs. 1 vs. 15 votes) - DatePeriod::__construct(): accepted, to be removed in PHP 9.0 (23 vs. 0 vs. 0 votes) - dba_fetch(): accepted, to be removed in PHP 9.0 (24 vs. 0 votes) - FFI::cast(), FFI::new(), and FFI

[PHP-DEV] Re: [RFC] [Vote] PHP 8.3 deprecations

4 vs. 10 votes) - "MT_RAND_PHP": accepted (28 vs. 0 votes) - "Global Mersenne Twister": rejected (13 vs. 16 votes) - "Calling ''ldap_connect'' with 2 parameters": accepted (26 vs. 0 votes) Thanks for everyone for their participation! Regards,

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

Hi Everyone, I'd like to let you know that I'm not going to propose "clone with" for PHP 8.3 in its current form due to the questions and possible complexity which were revealed during the last couple of emails. Hopefully, we'll be able to come up with something for PHP 8.4... Regards, Máté

[PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures

Hi Everyone, As previously announced on the list, I have just started the vote about the "Deprecate functions with overloaded signatures". Link to the RFC: https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures Link to the discussion thread: https://externals.io/message/120146 T

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

Hi Derick, In any case, I don't mind this — I'm actually going to suggest to change > the constructor to: > > public function __construct(DateTimeInterface $start, DateInterval > $interval, DateTimeInterface|int $end, int $options = 0) {} > > And then *only* add: > > public static function createF

[PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations

Hi Everyone, As previously announced on the list, we have just started the vote about the annual PHP deprecation RFC. Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3 Link to the discussion thread: https://externals.io/message/120422 The vote is open until 2023-07-06 12:00:00 UTC.

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

Hi Rowan and Larry, > Isn't that exactly what a deprecation period is for? > Yes, sure, but I wrote my arguments with the "Short deprecation period" in mind so that the removal of these functions causes the least pain. > If we want to give people longer, just leave the functionality deprecated

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

Hi Bruce, For those who use callbacks now, how is this in any way better? They will > eventually end up using an OOP approach anyway (as that's the strategic > goal). > Migrating from `session_set_handler_callbacks()` would still be > (potentially) > non-trivial. And what's the point migrating *to

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

HI Nicolas and Rowan, Mate, WDYT of 2)? Your sentence about better typing rang a bell with me: I think that's the best argument for removing the signature accepting callables. But before coming to a conclusion, let me answer Rowan's question first: This is where I don't understand what you or M

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

Hi Juliette, There are plenty of situations where it is of absolutely no interest to > get a crypographically secure value, like for generating some > semi-random test data and I strongly believe the impact of these > deprecations to be large and fixing it won't always be trivial for > codebases w

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

Hi Juliette, Respectfully though, in my opinion selectively leaving out impact analysis > without mentioning why they are missing in the RFC, reeks of trying to hide > information which could influence the vote. > Maybe just mentioning why the impact analysis is missing in these cases in > the RFC

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

Hi Juliette, For the mb_strimwidth() proposal an impact analysis is provided at the end ("over 100 projects were reviewed"). For the other proposals there isn't and we do not believe this to be useful. We consider deprecations to be different from other RFCs that add new features, because functio

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

Hi, The impact analysis on userland code seems to be missing for some of the > proposals, most notably for the proposals which I expect will have the > highest impact. I'd like to ask for an impact analysis to be added to > each of these: > * array_keys() > * ReflectionProperty::setValue() > Thes

Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations

Hi everyone, As there was no discussion and complaint for a long time, we would like to move forward with the RFC. We believe Go and Tim answered Nikita's doubts elaborately, so we should make the question decided during the vote. Therefore, we'll start the vote on Monday, unless new problems eme

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

> > Given that you've agreed that neither signature is "primary" or "better", > doesn't that argument apply equally to both signatures? If it's OK to force > anyone using individual callbacks to change their code, why is it not > equally OK to force anyone using an object to change their code? > A

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

Hey Nicolas, Instead of passing arguments to __clone(), I wondered about a new > __clone_with(array > $properties) that could be implemented next to __clone(), with the > following behavior: > >- if only __clone is implemented, same behavior as always >- if __clone_with is implemented, __c

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

Hi Nicolas, On my side, I'd very much prefer keeping the constructor of DatePeriod and > thus making it non-overloaded with this signature: > > public function __construct(DateTimeInterface $start, DateInterval > $interval, DateTimeInterface|int $end, int $options = 0) {} > > That'd help a lot wit

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

(Resending my earlier message to Levi:) Hi Levi, I apologize if this has been discussed before, as I have fallen very > behind on internals discussions. I think it would be helpful to add an > example where the object being cloned accesses its properties. > Something like this: > >$b = clone

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

Hi Larry, In this case, if the `with` happens first, then the new address object is > cloned needlessly, but that *probably* doesn't hurt anything. But $newAddr > !== $p3->address. > Yes, I agree with this: "clone $this with ["x" => "y"];" is the easiest to mentally model as a shorthand for "$se

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

> > It looks like the current preferred signature was only introduced in PHP > 8.2. Previously, the signatures were dba_fetch($key, $handle) and > dba_fetch($key, $skip, $handle) - it effectively had a non-final optional > parameter. > Yes, that's the case! Thanks for reminding me again, I clarifi

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

> > In my mind, the only reason to change anything about this function is that > we can't properly overload a function based on its argument types. There's > nothing particularly "primary" or "better" about either of the two > signatures, it's just hard to document and use named parameters while >

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

Hey Everyone, In the meanwhile, I noticed yet another overloaded function (dba_fetch()) and I included it into the proposal. In my opinion, it's a no-brainer to deprecate due to its low adoption rate and very odd behavior - to say at least. The RFC evolved a lot during the discussion phase, thank

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

I'm forwarding my mails which I managed to only address for Rowan: Hi Rowan, > If we go down that route, perhaps we should come up with a corresponding > name for the object based version - "session_set_handler_object" perhaps? > That would also mean the deprecation messages can be much simpler:

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

Hi Claude, The very risk is that the programmer must be aware that the return > convention has changed. Recall that not everyone run static analysers, > especially for such a trivial migration, and that not every code is > statically analysable (e.g.. `$foo->$bar()`). > I hope that I don't sound

  1   2   3   >