[PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Can we make sleep accept int|float? Made a PR: https://github.com/php/php-src/pull/13401 For years when I wanted to sleep for 0.1 seconds, it annoyed me that I couldn't do `sleep(0.1);` instead I had to do `usleep(figure out how many microseconds there are in 0.1 seconds and put it here);` FWIW Python's `time.sleep` also works like this: https://docs.python.org/3/library/time.html#time.sleep
[PHP-DEV] PHP 8.3.3 Released
The PHP development team announces the immediate availability of PHP 8.3.3. This is a bugfix release. All PHP 8.3 users are encouraged to upgrade to this version. For source downloads of PHP 8.3.3 please visit our downloads page:https://www.php.net/downloads Windows source and binaries can be found athttps://windows.php.net/download The list of changes is recorded in the ChangeLog:https://www.php.net/ChangeLog-8 Many thanks to all the contributors and supporters! Eric Mann, Jakub Zelenka, and Pierrick Charron Release Manifest here and below: https://gist.github.com/ericmann/8663ce02d29cc18dd86c268c053a71ef php-8.3.3.tar.bz2 SHA256 hash: aafb613ba79594a23fe722f8e90ad473300610bf80e74b8aa52da9cac2dc4e2a PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmXLjjAACgkQvsVV4ioU NVPQQBAApLCR+GNYNKXfCo6nmEkteXBNNA/Bl/oJq2tURtmFOCn/w6Y0ugh/Pi1Z XrV4zDEP1KBbNMOcpTA8kpJvjsHXs40donnBTwlRJzvhClaMDs0u2llBVynfp9VZ VLHJjplMQVaONlMaT15cvBnCD+yu1dxWU+oPLr5DLLW0OSqYy3s80fX45RXbKphn imIv52ZXT/dKWqvloBNY2z08c6eMQWgwjWV/e5ruf9xooVBCjvYh+wJnfelKLNq2 n1k8qMfRPiFIoLK8BEv9rkkJ6x8avY/WuGTeEwXmuY9JvB7rjMdjbpn3Q9jJ9BXu UvJ43dSrf0x79HlLfRWy6bJmKciz9B+qGEVc3gpK3xsjBJgRpLSVCEDSV6qCY2MJ IukHcXQqeQvUEfu/hVVH1xUlXQtUdJsFIQkUcx9p0+28/3JYBCuMTVzsRA/X2uzJ 5YzfehOv/MdWCDnyDIJ3c0GI7guJ5K9XyvyPj1UM/bBrCOhPmHhiWFDzbBzCIDUo uTVD4yar+wEUnPSFDBM4+Tqdojl48RTWgmcOPxuumFYy/iKjJPshP3JIexO4jw03 h+Bb30FeAlKA0VeCs4uIzatVNt5vR0+b+ltCAbpzajIhhKiYwZTCxgiVbtkBTBDO Pm1EZQ+qrd1nQ7vZaGGKd/heOMcN9iYAod/fyyDw9k6CQEHBqMc= =tqOd -END PGP SIGNATURE- php-8.3.3.tar.gz SHA256 hash: 61285ae17a93d172c9f2ebfe4280058d05bda17cadab705ca5b51ba3e6f3a5ac PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmXLjjEACgkQvsVV4ioU NVPS9w/+OvhRiu8Ygg0oPvx6/bE825OpBJc5zGiUKh0n/ChPb33mBBYge190bNAP 6cRd0LLXBkUpBuehS64cb53HIB5S282RvK8U1OaLgcwS9Wu/xHSpvPQdpyvp/lhh 5Ckq5Ln1SqEFTUZ6U1BAsuI/3D+beR3euPe+SUB7Rd1oTlv4sjM0B3GvCB89LnYd PPsXY7Z+JNoROIuiA9OziTv4Yb0YnIs0a37LYRoNnQhPFsTJ1IoVwpa91xzycUtM LQHyApcKUtQ2L4QZWmoeleTfpmvTZjnrMLMS0Z5mLKkwrcgHjzHhBva7iECcpNYf RPsd7ryKMckOls+qfYoxjFgVc81mSnKroN4efb3cHFFpC0rHKJuTa2VgrMCEeBpA nJocAHk755N1snwQ3JoDn+AQRMwB3yWEJ5mZzTz+vuzAJ9Ggom/054KE/TNXhwr7 dxfguCZ5GokeyQmD+CCy/tQnekhKhdwmmsvZbbcr4ol7vBy5QW4bcGqN1f5yBF/K qvvG6aURUkxQ8oAjdYM5jACkRnBugu52S/rtwtIT60kUJTczYyY+Xbzwjol0zRFz i+c1q+ovZPVrUypDtJO2GAsuOsamZjz6xBjYbGwV5804hAX+Smzcb8SbworU+Dnv gQOKkmncTZbKw8qNkKyS+JDGTAo7nH49pz0SFAM7dqO0AtShuTM= =XKnN -END PGP SIGNATURE- php-8.3.3.tar.xz SHA256 hash: b0a996276fe21fe9ca8f993314c8bc02750f464c7b0343f056fb0894a8dfa9d1 PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmXLjjEACgkQvsVV4ioU NVPfNQ/+IKcqs/ZP969iUiB3HsYUw8zHPd+Syda/HS1W/bbTW1QBwkzo6jhOUCSs zsdnq5UwniGIlhlGHWHR9UtD3Y3Zhq5lFgVUuRMcLEKW+s84alBEJ2B9DL/eKXK3 lnOEtKsqGhYb8JoQm+5DsKubKWwnJZXrQy6mxKyu/g6L6sA7g1nVjNobcgyZ+IC3 uU++HL4h23BU/hVTA79BGVLXZDVfjGOJEg6ybzplj1blGHgXkjc4ppFobBlUzeWp f558ksdB4atNjGLvIu0FZyOB2OqrB9B6MKIv3avQ5CMTrXVyp7RBlWBAbXPoMdlx yynAPoLdn02ke3OWO/TBcrINxtI1aQSkTFguRBGW3/2mC4ESvzW0PNZ8iEtsdEzo erMnSNcnPk9cC+lst19sBEJVmNehK40c84845w0AHe9Y62FoG9KT397ypzoUsS/5 T3/PBTO8bM53wr4vu7VCzBN2KdUrDb29eDdJTOmXYOBR2XtWqoatWI9OPFfeSH5y 0kr7FT/sF28723sxGzpSMtS3WdBUz/YB6ckqeH+IzSpCUscM3odKh4lkSOLRndRz yNZNsLiApcUq9FojPVWuNI6/BgfM+LtndgSYX83VrGwJcAt4+Kt1dhkRl+FsXhl0 8LxywrhQCa7/teGSw83DJoyaMo1OgALpQTvjwusEn4PmQa6mdbs= =Jtgl -END PGP SIGNATURE-
[PHP-DEV] Re: [RFC] OOP API for cURL extension
Summarizing replies so far. Won't be able to update the RFC immediately as my day job needs me, but some great discussions already, gang. Thanks! * Define the conditions under which exceptions will be thrown (and which exceptions) - I'll add these to the RFC, but in short: * CurlException - Never, it's an interface type to group the other exceptions. * CurlHandleException - Whenever a CurlHandle::method() fails (in lieu of returning false) * CurlMultiException - Same, but for the CurlMultiHandle class. * CurlShareException - Same, but for the CurlShareHandle class. * Naming styles, e.g getErrorNumber(): int vs errno() Comment: Agreed with your points. We don't have to stick to a hard line mapping of the function names. My initial translation did because my bugbear is with the lack of fluency and all the rest is just window dressing on that. Proposal: I'll rename all the new APIs according to a get*/set* scheme without abbreviations, e.g.: * CurlHandle::getErrorNumber(): int * CurlHandle::getError(): ?string * static CurlHandle::getErrorTextFromCode(int $code): ?string * CurlHandle::execute(): ?string // See late note about exec return values * CurlHandle::setOptionInt(int $option, int $value): CurlHandle * Better typing for setOpt() methods. Comment: Yep, this is a good and fair point. It's going to take a little more dicing up of the current implementation, but hopefully not too rough. Proposal: Keep untyped setOption() method (1/ Easier migration of existing code, 2/ Some options may prove difficult to type), but add: * CurlHandle::setOptionBool(int $option, bool $value): CurlHandle * CurlHandle::setOptionInt(int $option, int $value): CurlHandle * CurlHandle::setOptionString(int $option, string $value): CurlHandle * etc... as needed, will this get weird when we get to Array since there IS a setOptArray? Maybe we just don't mirror that one, or we call it setOptionMany(). Yeah, I like Many for the multiple option set, and Array for the single option of array type. Internally, the setopt handler will be split by type so that each typed setting can call explicitly, and the untyped one can call all. * CurlHandle::exec() mixed typing of return values. Comment: Agreed. The `true` return value becomes meaningless in the RETURNTRANSFER==false case. Proposal: Update the RFC for CurlHandle::execute() to return ?string. * https://php.watch/articles/php-curl-security-hardening Comment: I'll read this later when I'm updating the RFC. * Prefer class constants to global constants. Comment: I'm less compelled by this. The global scope is polluted with the constants whether we add copies or not. Adding a second way to spell the constant name only adds a second way to spell the constant name. Proposal: Change my mind? * Request and Response objects, along the lines of PSR-18 Comment: I'd be in favor of that, but it's not the mountain I'm personally trying to climb today. No offense taken if you vote no because this isn't enough, but I don't have the cycles to go in that hard. Proposal: Write an RFC (and get it passed) and I can probably help you implement it? -Sara
[PHP-DEV] RE: Testing new list server
Hello, In the past there was a List-Id header. This seems to be missing now. Is it expected to be added again? Else I will update my mail rules. Kind regards, Mark > -Original Message- > From: Derick Rethans > Sent: Wednesday, February 14, 2024 16:16 > To: Internals@lists.php.net > Subject: Testing new list server > > Please don't be alarmed, we're moving the lists over to a new machine.
[PHP-DEV] Re: [RFC] OOP API for cURL extension
On 14-02-2024 19:47, Sara Golemon wrote:
Good afternoon folks, I'd like to open discussion on adding OOP APIs to the
cURL extension.
https://wiki.php.net/rfc/curl-oop
This has been a long standing bug-bear of mine, and I think its time has
come.
try {
(new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
} catch (\CurlHandleException $ex) {
assert(false); // Why not?!
}
-Sara
I love the idea of an OOP API. Personally I use Python's Requests
library a lot, it could offer some inspiration. I would really like to
simply write:
Curl::get('https://...', params: ['key' => 'value'])->json()
Curl::post(...)
...
Some more specific exceptions may be nice too, to easily differentiate
between errors you might want to retry (network errors) and programming
errors.
Regards,
Dik
Re: [RFC] OOP API for cURL extension
On Wed, Feb 14, 2024 at 10:44 PM Sara Golemon wrote:
> Good afternoon folks, I'd like to open discussion on adding OOP APIs to
> the cURL extension.
> https://wiki.php.net/rfc/curl-oop
>
> This has been a long standing bug-bear of mine, and I think its time has
> come.
>
> try {
> (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
> } catch (\CurlHandleException $ex) {
> assert(false); // Why not?!
> }
>
> -Sara
>
Although I do not have voting karma, that'd be a +1 from me!
--
Atenciosamente,
Flávio Heleno
Re: [PHP-DEV] [Discussion] Thoughts on casting to null
EventLoop::repeat($pingInterval,
function(...$args)use($client){$client->ping(...$args)});
Re: [PHP-DEV] [Discussion] Thoughts on casting to null
I don't even know why lambda realization is not the same as in javascript.
```
let action = function () {
console.log('hello');
return 1;
}
let fn1 = () => action();
console.log(fn1()); // calls hello(), returns 1, for me, not a best way,
could be read like "call action() then create function that returns result
of that call"
let fn2 = () => (action());
console.log(fn2()); // calls hello(), returns 1, common, short way
// what's this?
(() => ())(); // could look strange? no, its declaring unnamed function
that does nothing and returns nothing and calls it immediately.
let fn3 = () => { action(); }
console.log(fn3()); // calls hello(), returns undefined, common, short
without return
let fn4 = () => action;
console.log(fn4()); // returns function, very handy for Promises, that
start init function immediate on new call, so it wraps function to "task"
available to call it later somewhere, maybe in another promise
```
Why is the PHP implementation redesigned from scratch instead of using the
idea of the one that works?
ps. Guess, the discussion to change syntax that you cold rewrite with
single line:
```
// > what?
// fn() => $client->ping() ? null : null
// > that
// static function () { $client->ping(); }
```
Ahh, the main problem in fn() is exactly that you don't like `use`
statement So long to write the `use` keyword.
Аnd you prefer the `js` implementation, which automatically uses the
current scope in your callback.
And you need something handy, that is allow create functions:
- with all variables (copy local state)
- with short syntax
- with return modes variety
- with return types and parameter types, if you need it
is more interesting, than talk about error collection that requires
rewriting half of the app
As I remember you say, you work on projects with a million lines of code
and you prefer correctness instead of simplification.
Why do you use short functions then? OOP awaits you.
Create a function that wraps function:
1. one function returns result (client.ping())
2. second one returns null|result (myclass.clientPingOrNull())
3. The third one catches the first one with a try catch to return the
result and return errors (myclass.tryClientPingOrNull())
4. then call that batch of correctness in your callback...
Sorry, couldn't resist myself
Another test-Email
Feel free to disregard. -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [RFC] OOP API for cURL extension
Working with remote servers is a little bit harder than just catching the exception. Just implement OOP stuff gives no benefit except "do not read the docs, but use IDE". Usually count of curl options is so big that it wont help. And also, there's multicurl too. There's batch calling with limit too. There's errors of different types. I mean curl errors on create, curl errors on execute, http errors (network), response errors (invalid data, misformatted data), and api errors, that could be sent even with 200 code. How try/catch will solve? Easy solution, too many discussion points.
Re: [RFC] OOP API for cURL extension
Am 15-Feb-2024 03:30:44 +0100 schrieb poll...@php.net:
> Good afternoon folks, I'd like to open discussion on adding OOP APIs to the
> cURL extension.
> https://wiki.php.net/rfc/curl-oop
>
> This has been a long standing bug-bear of mine, and I think its time has come.
>
> try {
> (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
> } catch (\CurlHandleException $ex) {
> assert(false); // Why not?!
> }
>
> -Sara
Hi Sara,
I like your proposal generally. But I'd suggest to rethink the names of the
methods. I understand that you want to reuse the same names of the procedural
version and the underlying lib. But this is the chance to optimize the naming
and reduce inconsistence. In the future this will become harder.
For example there is the getter "getInfo" and some getters without the "get"
prefix, like "errno", "error" and "strerror". I'd suggest to unify them. Either
use the "get" prefix for all of those or for none. Personally, I have no
particular preference for one of the two options.
The second thing I propose to change is the usage of abbreviations. I'd suggest
the following mapping for methods of CurlHandle:
- errno => errorNumber or getErrorNumber
- error => errorMessage or getErrorMessage
- strerror => errorMessageByNumber or getErrorMessageByNumber
- exec => execute
- setOpt => setOption
- setOptArray => setOptionArray
There may be better proposals from others.
What do you think?
Best regards,
Christian
Re: [RFC] OOP API for cURL extension
On 15/2/24 05:47, Sara Golemon wrote: Good afternoon folks, I'd like to open discussion on adding OOP APIs to the cURL extension. https://wiki.php.net/rfc/curl-oop Thanks for making this. It's certainly an improvement, but it's disappointing to see such a conservative change when the extension interface is so weird and awkward. I'm sure you know what I mean. It's easy to forget how bad it is until you have to do something without a framework, or explain it to a new developer. I guess the proper fix would be to add a new extension with new names for everything, with Request and Response objects, along the lines of PSR-18. But if I can think of a few minor backwards-compatible changes which would improve things a bit. For example, getInfo() could be split out to separate read-only properties. And setOpt() could be split out to separate chainable mutator methods. That would improve type inference in surrounding code. I see CurlHandle::exec() does not have the same return value as curl_exec() in your proposal, since errors are promoted to exceptions. But it still has a union return type. I would take it one step further, and have it unconditionally return either a string or void. Having it return a string is defensible if you consider it to be returning the final value of the body buffer. Enable CURLOPT_RETURNTRANSFER by default. If CURLOPT_WRITEFUNCTION or CURLOPT_FILE is set and thus the buffer doesn't get appended to, naturally curl_exec() will return an empty string. -- Tim Starling
Re: [RFC] OOP API for cURL extension
> Sara Golemon hat am 14.02.2024 19:47 CET geschrieben:
>
>
> Good afternoon folks, I'd like to open discussion on adding OOP APIs to the
> cURL extension.
> https://wiki.php.net/rfc/curl-oop
>
> This has been a long standing bug-bear of mine, and I think its time has come.
>
> try {
> (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
> } catch (\CurlHandleException $ex) {
> assert(false); // Why not?!
> }
>
> -Sara
Thanks a lot for the rfc.
Regarding secure default options, I'd like to mention this article:
https://php.watch/articles/php-curl-security-hardening
Since CurlHandle::setOpt() no longer returns true on success, it would be good
to have an example in the RFC how error handling should be implemented in user
land regarding setting invalid, deprecated or unknown options (e.g. SSLVERSION
received some changes over the years:
https://curl.se/libcurl/c/CURLOPT_SSLVERSION.html).
Also I'd prefer to have class constants for the options, e.g. CURLOPT::TIMEOUT
instead of CURLOPT_TIMEOUT.
Static code analysis for curl_getinfo() is currently difficult to implement
(see
https://github.com/phpstan/phpstan-src/blob/1.11.x/src/Type/Php/CurlGetinfoFunctionDynamicReturnTypeExtension.php).
So I'd suggest adding sth. like curl_getinfo_all():CurlInfo-Class if possible.
Maybe Ondrej also has some suggestions regarding a more object oriented version
or curl_setopt(CurlOption-Class)? (see
https://github.com/phpstan/phpstan-src/blob/1.11.x/src/Reflection/ParametersAcceptorSelector.php#L562)
Regards
Thomas
Re: [RFC] OOP API for cURL extension
I love it! When is CurlMultiException and CurlShareException thrown? I feel like this part in general is not very clear in the RFC.
Re: [RFC] OOP API for cURL extension
On Thu, 15 Feb 2024 at 03:53, Sara Golemon wrote:
> Good afternoon folks, I'd like to open discussion on adding OOP APIs to
> the cURL extension.
> https://wiki.php.net/rfc/curl-oop
>
> This has been a long standing bug-bear of mine, and I think its time has
> come.
>
> try {
> (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
> } catch (\CurlHandleException $ex) {
> assert(false); // Why not?!
> }
>
> -Sara
>
Good morning from this side of the globe Sara! :)
"Hell... It's about damn time" (c) Tychus, StarCraft 2.
The proposed API looks good to me and covers it all as far as I can tell.
--
Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius
