Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
On 18 February 2024 15:26:37 GMT, Lynn wrote: > Having a lot of setters for options might make it really hard to find the >methods you're looking for in terms of auto-complete in your IDE. I think it would be significantly better for that purpose than what we have now, because there would be a lot fewer methods than there are current option constants. Firstly, because most of the methods would cover multiple overlapping or related options - e.g. setHttpMethod(string $method) covers CURLOPT_POST, CURLOPT_PUT, CURLOPT_CUSTOMREQUEST, and CURLOPT_HTTPGET; setBasicAuth($username, $password) combines CURLOPT_HTTPAUTH, CURLOPT_USERNAME, and CURLOPT_PASSWORD. Secondly, because some functionality that's not used as often can just be left to the curl_setopt equivalents forever, e.g. we don't need new methods for CURLOPT_DNS_SHUFFLE_ADDRESSES, CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS, etc, etc. The initial aim could be to cover, say, the 10 most commonly used settings - things like choosing the request method, and including custom request headers. Over time, we could add more methods for common tasks, but continue adding constants / enum cases for more obscure features of the library. > Would it >make sense to split options into a separate object (or perhaps multiple), >that could in theory also be shared between different CurlHandle instances? While I'm not against splitting things up into more objects, I think that becomes a much bigger task to define what goes in each, and harder to do half-way. My gut feeling is that it would descend into a lot of bikeshedding, and stop us making progress; whereas adding a few methods for common use cases could present a real quick win. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] automatic formatting checks for pull requests?
On Sun, Feb 18, 2024 at 4:11 PM Gina P. Banyard wrote: > > On Saturday, 17 February 2024 at 22:18, Ilija Tovilo > wrote: > > > * The new code style should be applied only to newly added sections or > > changed code, not entire files. Otherwise, we'll have many changes in > > large files, with endless merge conflicts when merging up from lower > > branches. > > Surely the best way is to apply the formatting tool on all branches that are > supported (even in security support). > Have them be merged upwards, and then add the revisions of the commits to a > .git-blame-ignore-revs file so that git blame doesn't care about them. > > This should resolve the issue of making future merges difficult. Presumably, this would lead to merge conflicts in every open pull request. Maybe a resolution strategy could be automated, not ideal nonetheless. Additionally, given that the PR has discovered a clang-format bug that changes behavior (https://github.com/php/php-src/pull/13417#issuecomment-1950920114), I'd be wary of applying the formatting blindly to our stable branches.
Re: [PHP-DEV] New ext-dom features
On Sat, Feb 17, 2024, at 5:11 PM, Niels Dossche wrote: > Hi internals > > After (and if) my current in-voting RFC about spec-compliance DOM > passes, some features become more easily possible to implement due to > the necessary building blocks becoming in place in the extension code. > > I would like to start implementing those. Therefore, I'd like to gauge > the opinion of the community on the following two features before > making an actual RFC and sitting through the process again. > > 1) Helper functions for CSS classes (i.e. classList). Requested here: > https://github.com/php/php-src/issues/11688 > > This feature would add the DOMTokenList class along with the classList > property to the Element class. > It exists to ease the managing of CSS classes on elements, i.e. it > deals with whitespace, duplicate class names, etc all for you using a > simple set-like API. > > I expect that implementing this into the DOM extension is not too > difficult, as the spec steps are really straight-forward [1] and we > just have to reuse the internal APIs to manage attributes. > > 2) Built-in CSS selector API support > > In particular, Element::querySelector(All), Element::matches, and > Element::closest support. > For "old DOM" there is a trick to at least implement querySelector(All) > in userland, and that is to translate the selector to XPath and use > XPath queries internally. However, that's slower and more cumbersome > than a native implementation. It's also just silly to not have this > natively available since it's so commonly used. > > I have a prototype implementation of this already actually, because I > got bored while fixing spec-compliance issues and wanted some funner > stuff to do. It's based on Lexbor's CSS support. > > > Kind regards > Niels > > [1] https://dom.spec.whatwg.org/#interface-domtokenlist I feel like the CSS-based querySelector() was discussed not that long ago. Was it by you? Lexbor sounds familiar. Either way, I'm +1 on including a CSS selector natively. --Larry Garfield
Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
On Sun, Feb 18, 2024 at 12:41 PM Rowan Tommins
wrote:
> On 17 February 2024 15:57:20 GMT, Larry Garfield
> wrote:
>
> >The RFC would also benefit greatly from some practical examples of using
> the new API. Right now it's not clear to me (as someone who almost never
> uses Curl directly) how/why I'd use any of these, since there's still "a
> whole crapton of int constants I don't understand floating around." The
> suggestion to use an Enum (or several) here is a good one and would help a
> lot with that, so I'm +1 there.
>
> To my mind, the *eventual* aim should be that users don't *need* a
> userland wrapper just to make a simple request in a readable way, and that
> setting raw curl options becomes an advanced feature that most users never
> need.
>
> I know a lot of people's minds will immediately go to request and response
> objects, but I think we can go a long way by just making well-named methods
> wrapping one or two curl options each, so that you could write this:
>
> $ch = new CurlHandle('https://example.com');
> $ch->setMethod('POST');
> $ch->setRequestBody('{"stuff":"here"}');
> $ch->setBasicAuth('admin', 'correct-horse-battery-staple');
> $result = $ch->executeAndReturn();
>
> Note that I am not saying every one of those methods needs to be added
> right now; adding a few at a time may be sensible to have time to discuss
> good names and signatures. But to me, renaming CURLOPT_POSTFIELDS to
> Curl\StringOptionsEnum::POSTFIELDS doesn't get us very far - users
> shouldn't need a raw curl setting for such a basic feature in the first
> place.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
Having a lot of setters for options might make it really hard to find the
methods you're looking for in terms of auto-complete in your IDE. Would it
make sense to split options into a separate object (or perhaps multiple),
that could in theory also be shared between different CurlHandle instances?
Re: [PHP-DEV] automatic formatting checks for pull requests?
On Saturday, 17 February 2024 at 22:18, Ilija Tovilo wrote: > Right. Consistent code style is nice, but what we have now is really > not that bad. There are a couple things I'd want if we enforce code > style: > > * Fixing the style should be easy, running a single command without > first pushing to CI. > * It should be fast too, so that I can easily run it for every commit, > preferably even on-save in my editor. > * The new code style should be applied only to newly added sections or > changed code, not entire files. Otherwise, we'll have many changes in > large files, with endless merge conflicts when merging up from lower > branches. Surely the best way is to apply the formatting tool on all branches that are supported (even in security support). Have them be merged upwards, and then add the revisions of the commits to a .git-blame-ignore-revs file so that git blame doesn't care about them. This should resolve the issue of making future merges difficult. Best regards, Gina P. Banyard
Re: [PHP-DEV] RE: Testing new list server
On 18 February 2024 12:08:46 GMT, Frederik Bosch wrote: > >On 18-02-2024 11:47, Derick Rethans wrote: >> On 18 February 2024 10:23:59 GMT, Matthew Sewell wrote: >>> Hi, >>> >>> I'm using Gmail too but with a custom domain. I did get those three >>> messages but significantly delayed from when they were on externals. >> That sounds about right. The queue was backed up due to rate limiting for >> 10+ hours. This should no longer be the case, and all messages should now >> have been delivered. >> >> cheers >> Derick >> >> >>> On Sat, Feb 17, 2024 at 4:15 PM tag Knife wrote: >>> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa wrote: > Hello Derick, > there is something wrong. I don't get all of the emails from the new > setup, only part. Examples of emails I didn't receive: > - https://externals.io/message/122391 > - https://externals.io/message/122390 > - https://externals.io/message/122388 > > I'm using Gmail and Spam doesn't contain any of them. > > Kind regards, > Jorg > Same, I did not receive messages - 122402 - 122372 - 122376 >Hi Derick, > >I tried to unsubscribe but I get a 550 from php-smtp4.php.net. > >550 5.1.1 : Recipient address > rejected: User unknown in local recipient table (in reply to RCPT TO > command) > >Is that also due to the new server, or is that perhaps my own mistake? > >Regards, >Frederik A bit of both. The separator changed from - to + with the server change, but I've only more recently updated that change in the headers that the lists add. Cheers Derick
Re: [PHP-DEV] RE: Testing new list server
On 18-02-2024 11:47, Derick Rethans wrote: On 18 February 2024 10:23:59 GMT, Matthew Sewell wrote: Hi, I'm using Gmail too but with a custom domain. I did get those three messages but significantly delayed from when they were on externals. That sounds about right. The queue was backed up due to rate limiting for 10+ hours. This should no longer be the case, and all messages should now have been delivered. cheers Derick On Sat, Feb 17, 2024 at 4:15 PM tag Knife wrote: On Fri, 16 Feb 2024 at 23:50, Jorg Sowa wrote: Hello Derick, there is something wrong. I don't get all of the emails from the new setup, only part. Examples of emails I didn't receive: - https://externals.io/message/122391 - https://externals.io/message/122390 - https://externals.io/message/122388 I'm using Gmail and Spam doesn't contain any of them. Kind regards, Jorg Same, I did not receive messages - 122402 - 122372 - 122376 Hi Derick, I tried to unsubscribe but I get a 550 from php-smtp4.php.net. 550 5.1.1 : Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command) Is that also due to the new server, or is that perhaps my own mistake? Regards, Frederik
Re: [PHP-DEV] RE: Testing new list server
On 18 February 2024 10:23:59 GMT, Matthew Sewell wrote: >Hi, > >I'm using Gmail too but with a custom domain. I did get those three >messages but significantly delayed from when they were on externals. That sounds about right. The queue was backed up due to rate limiting for 10+ hours. This should no longer be the case, and all messages should now have been delivered. cheers Derick >On Sat, Feb 17, 2024 at 4:15 PM tag Knife wrote: > >> >> On Fri, 16 Feb 2024 at 23:50, Jorg Sowa wrote: >> >>> Hello Derick, >>> there is something wrong. I don't get all of the emails from the new >>> setup, only part. Examples of emails I didn't receive: >>> - https://externals.io/message/122391 >>> - https://externals.io/message/122390 >>> - https://externals.io/message/122388 >>> >>> I'm using Gmail and Spam doesn't contain any of them. >>> >>> Kind regards, >>> Jorg >>> >> >> Same, I did not receive messages >> - 122402 >> - 122372 >> - 122376 >> >>
Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
On 17 February 2024 15:57:20 GMT, Larry Garfield wrote:
>The RFC would also benefit greatly from some practical examples of using the
>new API. Right now it's not clear to me (as someone who almost never uses
>Curl directly) how/why I'd use any of these, since there's still "a whole
>crapton of int constants I don't understand floating around." The suggestion
>to use an Enum (or several) here is a good one and would help a lot with that,
>so I'm +1 there.
To my mind, the *eventual* aim should be that users don't *need* a userland
wrapper just to make a simple request in a readable way, and that setting raw
curl options becomes an advanced feature that most users never need.
I know a lot of people's minds will immediately go to request and response
objects, but I think we can go a long way by just making well-named methods
wrapping one or two curl options each, so that you could write this:
$ch = new CurlHandle('https://example.com');
$ch->setMethod('POST');
$ch->setRequestBody('{"stuff":"here"}');
$ch->setBasicAuth('admin', 'correct-horse-battery-staple');
$result = $ch->executeAndReturn();
Note that I am not saying every one of those methods needs to be added right
now; adding a few at a time may be sensible to have time to discuss good names
and signatures. But to me, renaming CURLOPT_POSTFIELDS to
Curl\StringOptionsEnum::POSTFIELDS doesn't get us very far - users shouldn't
need a raw curl setting for such a basic feature in the first place.
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] RE: Testing new list server
Hi, I'm using Gmail too but with a custom domain. I did get those three messages but significantly delayed from when they were on externals. Best wishes, Matt On Sat, Feb 17, 2024 at 4:15 PM tag Knife wrote: > > On Fri, 16 Feb 2024 at 23:50, Jorg Sowa wrote: > >> Hello Derick, >> there is something wrong. I don't get all of the emails from the new >> setup, only part. Examples of emails I didn't receive: >> - https://externals.io/message/122391 >> - https://externals.io/message/122390 >> - https://externals.io/message/122388 >> >> I'm using Gmail and Spam doesn't contain any of them. >> >> Kind regards, >> Jorg >> > > Same, I did not receive messages > - 122402 > - 122372 > - 122376 > >
