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

On Sat, 2024-09-14 at 15:33 +, Gina P. Banyard wrote: > Hello internals, > > I came across the Directory class while doing some code exploration > of ext/standard. > This class is effectively an opaque object for Directory resources, > however it doesn't behave like one, as it has existed sinc

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Mon, Aug 26, 2024, at 10:44 AM, Jim Winstead wrote: > Hi, > > Another RFC around process: > https://wiki.php.net/rfc/web-and-doc-use-not-endorsement > > Feedback would be appreciated. My intention is to start voting on September > 9th unless there is still ongoing discussion. It has taken m

Re: [PHP-DEV] [RFC] Warn on conversions from resource to string

Hi, ssh2 maintainer here. Low maintenance is indeed somewhat accurate. I review and merge PR's, have done some minor work on it, and do releases sometimes. Some others on this list have done minor work on it too. On Tue, Sep 24, 2024, at 19:53, Christoph M. Becker wrote: > >>> Let me know what

Re: [PHP-DEV] [RFC] Warn on conversions from resource to string

On 24.09.2024 at 19:21, Gina P. Banyard wrote: > On Tuesday, 24 September 2024 at 14:24, Christoph M. Becker > wrote: > >> On 24.09.2024 at 14:18, Gina P. Banyard wrote: >> >>> Let me know what you think about it: >>> https://wiki.php.net/rfc/warn-resource-to-string >> >> The ssh2 wrappers[1] us

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

On Tuesday, 24 September 2024 at 14:34, Christian Schneider wrote: > Am 14.09.2024 um 17:33 schrieb Gina P. Banyard intern...@gpb.moe: > > > I came across the Directory class while doing some code exploration of > > ext/standard. > > This class is effectively an opaque object for Directory res

Re: [PHP-DEV] [RFC] Warn on conversions from resource to string

On Tuesday, 24 September 2024 at 14:24, Christoph M. Becker wrote: > On 24.09.2024 at 14:18, Gina P. Banyard wrote: > > > I would like to propose a short RFC about warning on conversions from > > resources to strings, > > similar to what a conversion from array to string does. > > > > Let me

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

Am 14.09.2024 um 17:33 schrieb Gina P. Banyard : > I came across the Directory class while doing some code exploration of > ext/standard. > This class is effectively an opaque object for Directory resources, however > it doesn't behave like one, as it has existed since PHP 4. > > As such, I am p

Re: [PHP-DEV] [RFC] Warn on conversions from resource to string

On 24.09.2024 at 14:18, Gina P. Banyard wrote: > I would like to propose a short RFC about warning on conversions from > resources to strings, > similar to what a conversion from array to string does. > > Let me know what you think about it: > https://wiki.php.net/rfc/warn-resource-to-string Th

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

On Saturday, 14 September 2024 at 16:33, Gina P. Banyard wrote: > Hello internals, > > I came across the Directory class while doing some code exploration of > ext/standard. > This class is effectively an opaque object for Directory resources, however > it doesn't behave like one, as it has e

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hi Am 2024-09-05 18:03, schrieb John Coggeshall: I would suggest we take a step back from this and look at it with a bit more of a wider lens. It seems to me that this would be a good place to have an attribute (e.g. #[NotSerializable] ) that could be defined for any class (with ZEND_ACC_NOT_S

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

On 17.09.2024 at 18:03, Gina P. Banyard wrote: > On Saturday, 14 September 2024 at 18:48, Christoph M. Becker > wrote: > >> On 14.09.2024 at 17:33, Gina P. Banyard wrote: >> >>> RFC: https://wiki.php.net/rfc/directory-opaque-object >> >> As I see it, an opaque object is an object which doesn't h

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

On Saturday, 14 September 2024 at 18:48, Christoph M. Becker wrote: > On 14.09.2024 at 17:33, Gina P. Banyard wrote: > > > I came across the Directory class while doing some code exploration of > > ext/standard. > > This class is effectively an opaque object for Directory resources, however >

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

On Monday, 16 September 2024 at 18:31, Derick Rethans wrote: > On Sat, 14 Sep 2024, Gina P. Banyard wrote: > > > I came across the Directory class while doing some code exploration of > > ext/standard. This class is effectively an opaque object for Directory > > resources, however it doesn't beh

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

On 16.09.2024 at 18:31, Derick Rethans wrote: > On Sat, 14 Sep 2024, Gina P. Banyard wrote: > >> I came across the Directory class while doing some code exploration of >> ext/standard. This class is effectively an opaque object for Directory >> resources, however it doesn't behave like one, as it

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

On Sat, 14 Sep 2024, Gina P. Banyard wrote: > I came across the Directory class while doing some code exploration of > ext/standard. This class is effectively an opaque object for Directory > resources, however it doesn't behave like one, as it has existed since > PHP 4. > > As such, I am prop

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] [RFC] Change Directory class to behave like an opaque object

On 14.09.2024 at 17:33, Gina P. Banyard wrote: > I came across the Directory class while doing some code exploration of > ext/standard. > This class is effectively an opaque object for Directory resources, however > it doesn't behave like one, as it has existed since PHP 4. > > As such, I am pro

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Fri, Sep 6, 2024, at 20:07, Claude Pache wrote: > > >> Le 5 sept. 2024 à 18:03, John Coggeshall a écrit : >> >> >>> As per my previous email to the list, I have now created the official RFC >>> to deprecate calling json_serialize() on instances of classes marked with >>> ZEND_ACC_NOT_SERI

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Sep 6 2024, at 2:07 pm, Claude Pache wrote: > > > > Le 5 sept. 2024 à 18:03, John Coggeshall a écrit : > > > > > As per my previous email to the list, I have now created the official RFC > > > to deprecate calling json_serialize() on instances of classes marked with > > > ZEND_ACC_NOT_SERI

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> Le 5 sept. 2024 à 18:03, John Coggeshall a écrit : > > > As per my previous email to the list, I have now created the official RFC to > deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. > > I would suggest we take a step back from this and

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hello Philip, Thank you for your RFC, which is a great effort to improve serialization in PHP. Generators are indeed super useful and working with them should not be confusing. I regret that I missed your previous emails, but I would like to suggest that you consider the following concerns: 1. T

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> So if we had a #[NotSerializable] attribute (which I agree might be a good > idea) it would be implemented by setting the ZEND_ACC_NOT_SERIALIZABLE flag > on a class definition, and if this RFC passes, it would automatically apply > to json_encode() as well as serialize(). > My mistake, I hav

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Thu, 5 Sep 2024, at 17:03, John Coggeshall wrote: > I would suggest we take a step back from this and look at it with a bit more > of a wider lens. It seems to me that this would be a good place to have an > attribute (e.g. `#[NotSerializable]` ) that could be defined for any class > (with `

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> As per my previous email to the list, I have now created the official RFC to > deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. I would suggest we take a step back from this and look at it with a bit more of a wider lens. It seems to me that

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hello Rob, > To add to this, we apparently use json_encode at work to serialize custom > exceptions, which appears to work. This RFC would break that, I think. > > Exception is not marked as ZEND_ACC_NOT_SERIALIZABLE and would not be affected. Philip

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Thu, Sep 5, 2024, at 10:55, Alexandru Pătrănescu wrote: > > On Tue, Sep 3, 2024 at 2:27 PM Philip Hofstetter > wrote: >> Hello, >> >> As per my previous email to the list, I have now created the official RFC to >> deprecate calling json_serialize() on instances of classes marked with >>

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Tue, Sep 3, 2024 at 2:27 PM Philip Hofstetter wrote: > Hello, > > As per my previous email to the list, I have now created the official RFC > to deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. > > https://wiki.php.net/rfc/deprecate-json_encod

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hello Rob, I think it would be good to list these non-serializable objects in the RFC. > It doesn't have to be exhaustive, but the list includes throwables, > weak-maps, weak-references, closures, fibers, etc. Some people may be > relying on this behavior (and I'd be curious to know that use cas

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Tue, Sep 3, 2024, at 13:24, Philip Hofstetter wrote: > Hello, > > As per my previous email to the list, I have now created the official RFC to > deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. > > https://wiki.php.net/rfc/deprecate-json_enc

Re: [PHP-DEV] RFC: Default Expression

Hi all, I've been following the discussion on the Default Expression RFC, and while I appreciate the effort to introduce more flexibility in handling default values, I have some significant concerns about this proposal. I'd like to share my thoughts and invite further discussion. 1. Complexity vs

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

On Mon, Aug 26, 2024, at 2:40 AM, Máté Kocsis wrote: > 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 ad

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Mon, Aug 26, 2024, at 10:54 AM, Deleu wrote: > Hi Jim! > > On Mon, Aug 26, 2024 at 2:48 PM Jim Winstead wrote: >> __ >> Hi, >> >> Another RFC around process: >> https://wiki.php.net/rfc/web-and-doc-use-not-endorsement >> >> Feedback would be appreciated. My intention is to start voting on S

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On 28/08/2024 09:00, Rob Landers wrote: If anyone can add something to the list, then it eventually will become as overwhelming as https://github.com/uhub/awesome-php FYI, that's not the Awesome PHP list, this is: https://github.com/ziadoz/awesome-php. That other one doesn't even look curated

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Aug 28 2024, at 9:34 am, Larry Garfield wrote: > > I don't think I'd support a list of "popular" frameworks, but mentioning > Composer, Xdebug, and PHPUnit seems a requirement for a useful modern > tutorial. Can you explain your position more here, what exactly is your concern (if I captu

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

> I agree with this to a point. What if I want my newish framework listed on > the page? What are the qualifications for being listed (or unlisted) there? > Can anyone add their own framework? Personally I say put the top 5 by Github stars on a page by themselves, and have a secondary page rank

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

> > What a couple of people have touched on is that that all we have > right now is a Reference, which is only one kind of documentation.  > The common zeitgeist these days says there's 4: https://diataxis.fr/ > > * Tutorials > * How-to guides > * Explanation > * Reference > > We have a referenc

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Wed, Aug 28, 2024, at 2:51 AM, John Coggeshall wrote: >> And that is how you will find that the "new" languages will "win". If we >> don't promote how modern PHP Development works, then there will be more >> "PHP, a fractal of bad design" articles to come for decades. >> >> We *must* do better

Re: [PHP-DEV] [RFC] Static Constructor

Hello, everyone. I'm sorry for not being active for a time on the internals, including about this RFC of mine. I just had a huge house-related problem and recently also health problems with my family. So, I'll have to stay away for some time. But I'll go ahead with the talks about this RFC as soon

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Wed, Aug 28, 2024, at 09:51, John Coggeshall wrote: > >> And that is how you will find that the "new" languages will "win". If we >> don't promote how modern PHP Development works, then there will be more >> "PHP, a fractal of bad design" articles to come for decades. >> >> We *must* do better

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

> And that is how you will find that the "new" languages will "win". If we > don't promote how modern PHP Development works, then there will be more > "PHP, a fractal of bad design" articles to come for decades. > > We *must* do better than this. It probably doesn't all need to be in the > documen

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-partyPackages in PHP Documentation and Web Projects

On Wed, Aug 28, 2024, at 03:46, Jim Winstead wrote: > On Tue, Aug 27, 2024, at 4:46 AM, Christoph M. Becker wrote: > > On 27.08.2024 at 07:03, Andreas Heigl wrote: > > > >> I see this a bid differently to be honest. While I understand that using > >> third party packages in our internal tools mig

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-partyPackages in PHP Documentation and Web Projects

On Tue, Aug 27, 2024, at 4:46 AM, Christoph M. Becker wrote: > On 27.08.2024 at 07:03, Andreas Heigl wrote: > >> I see this a bid differently to be honest. While I understand that using >> third party packages in our internal tools might make things easier in >> the short term it will cause a lot o

Re: [PHP-DEV] [RFC] Static Constructor

On 2024-08-28 09:51, Bilge wrote: On 19/06/2024 19:25, Tim Düsterhus wrote: Hi On 6/19/24 16:03, Erick de Azevedo Lima wrote: I have considered some names, actually. I just chose this one for the implementation because I tried to design it to be as close as possible to the C# implementation an

Re: [PHP-DEV] [RFC] Static Constructor

On 19/06/2024 19:25, Tim Düsterhus wrote: Hi On 6/19/24 16:03, Erick de Azevedo Lima wrote: I have considered some names, actually. I just chose this one for the implementation because I tried to design it to be as close as possible to the C# implementation and they call it "static constructor"

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

> > Just like our home page is just boring release announcements. This > should have much more interesting stuff such as how, and when, to use > the great new features that we have been adding in the last decade. > I would add that there are lots of features where the PHP manual says how the

Re: [PHP-DEV] [RFC] Default expression

On 27/08/2024 16:03, John Bafford wrote: I'm not sure this could even work at all. The "default" parameter to gettype() isn't the default value of the third parameter to json_encode(). It's the default value of the first parameter to gettype(). Which would probably fail, since gettype()'s first p

Re: [PHP-DEV] [RFC] Default expression

> On Aug 27, 2024, at 10:14, Rowan Tommins [IMSoP] wrote: > > The only expressions that are in some sense "safe" are those that can apply > equally to any possible type that the function could in future set as the > default. In theory, that includes a match statement with an arm of "default

Re: [PHP-DEV] [RFC] Default expression

On 27 August 2024 14:14:03 BST, Bilge wrote: > Whilst the applications beyond use in conditionals still strikes me as > limited, it also appears equally harmless.  Though the number of people whom > feel its use in expression should be limited is steadily growing, I'm still > waiting on some

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

Missatge de Deleu del dia dt., 27 d’ag. 2024 a les 13:55: > > > > On Tue, Aug 27, 2024 at 2:06 AM Andreas Heigl wrote: >> >> >> I see this a bid differently to be honest. While I understand that using >> third party packages in our internal tools might make things easier in >> the short term it w

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-partyPackages in PHP Documentation and Web Projects

On 27.08.2024 at 13:34, Derick Rethans wrote: > Explaining how to install PHP with homebrew, apt or yum makes perfect > sense to me. Nobody really ought to go to www.php.net/download and > compile PHP themselves. But that's the only installation instructions > that we have. Well, it's not *that*

Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath

Hi Valentin, > 2024/08/25 9:14、Valentin Udaltsov のメール: > > On Thursday, May 16 2024 at 17:22, Saki Takamachi > wrote: >> Hi all, >> >> > 2024/05/01 17:55、Saki Takamachi > > >のメール: >> > >> > Hi all! >> > >> > Voting for RFC: Support object type i

Re: [PHP-DEV] [RFC] Default expression

On 27/08/2024 12:56, Derick Rethans wrote: Using 'default' as a place holder for (not) passing an argument seems useful. I am however much uncertain about using composition with the keyword in expressions. Presumably you mean ternary and null coalesce would still be acceptable? Otherwise, it is

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-partyPackages in PHP Documentation and Web Projects

Hey Christoph, hey all. Am 27.08.24 um 13:46 schrieb Christoph M. Becker: On 27.08.2024 at 07:03, Andreas Heigl wrote: I see this a bid differently to be honest. While I understand that using third party packages in our internal tools might make things easier in the short term it will cause a

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On 27.08.2024 at 12:37, Gina P. Banyard wrote: > We promote some installation methods, but not all, and when one project wrote > docs to be included it has remained in limbo for 2 years. [2] > > [2] https://github.com/php/doc-en/pull/1674 Well, that is about a freemium product, and we may want t

Re: [PHP-DEV] [RFC] Default expression

On Sat, 24 Aug 2024, Bilge wrote: > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think > some of you might enjoy this one. Hit me with any feedback. I liked this up to the point where I saw: $f = fn ($v = 1, $default = 2) => $v + $default; var_dump($f(defaul

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Tue, Aug 27, 2024 at 2:06 AM Andreas Heigl wrote: > > I see this a bid differently to be honest. While I understand that using > third party packages in our internal tools might make things easier in > the short term it will cause a lot or additional work in the long term. > > Currently we hav

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-partyPackages in PHP Documentation and Web Projects

On 27.08.2024 at 07:03, Andreas Heigl wrote: > I see this a bid differently to be honest. While I understand that using > third party packages in our internal tools might make things easier in > the short term it will cause a lot or additional work in the long term. > > Currently we have a lot of

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Tue, 27 Aug 2024, Gina P. Banyard wrote: > Moreover, PECL extensions are part of the PHP ecosystem and not the > runtime, so why do *some* PECL extension have the right to live on the > php.net website, but not others? They always were *allowed* to be on there. It is just that very few thir

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Mon, 26 Aug 2024, Deleu wrote: > On Mon, Aug 26, 2024 at 3:12 PM Bob Weinand wrote: > > > Thanks for bringing this up - I also suggest that we make this a > > binary choice - either we adopt the proposed language or its > > opposite. > > > > I.e. a rejection of this should codify that state

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Monday, 26 August 2024 at 20:06, Bob Weinand wrote: > I do in particular reject the notion that we should document third-party > projects (usage for our infra is fine). > > The point of the PHP documentation is to describe the PHP runtime and PECL > extensions, which are both officially dist

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024 at 11:58 PM Bilge wrote: > In case it matters, my initial inclination was also to do what some others > have suggested, and modify the SEND opcodes so that the default is not > actually looked up using reflection at all, but rather we just send nothing > to the function and i

Re: [PHP-DEV] [RFC] Default expression

On Tue, Aug 27, 2024 at 6:23 AM John Coggeshall wrote: > > But let's not just say "no expressions" - I think there's been some > demonstrated value from a lot of these. > > > Honest to god I don't think I've read from one person to come out and say > "no expressions". > Well... I think it's caus

Re: [PHP-DEV] [RFC] Default expression

On 27 August 2024 05:20:32 BST, John Coggeshall wrote: >> I DO think there are likely whole categories of expressions we can likely >> say "no" to - anything where the default represents a union type (and >> _mixed_ is a union type) should likely only allow default by itself or as a >> bare

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

Hey all Am 26.08.24 um 20:06 schrieb Bob Weinand: Hey Jim, On 26.8.2024 19:44:18, Jim Winstead wrote: Hi, Another RFC around process: https://wiki.php.net/rfc/web-and-doc-use-not-endorsement Feedback would be appreciated. My intention is to start voting on September 9th unless there is st

Re: [PHP-DEV] [RFC] Default expression

On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney wrote: > You'll likely identify the increased delay in such cases. Generally speaking > these sorts of default values don't change a ton, but it's not unlikely that > you may say "I'd like half that delay" or "twice that delay". But a better

Re: [PHP-DEV] [RFC] Default expression

On Aug 26 2024, at 5:57 pm, Bilge wrote: > In case it matters, my initial inclination was also to do what some others > have suggested, and modify the SEND opcodes so that the default is not > actually looked up using reflection at all, but rather we just send nothing > to the function and it

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Mon, 26 Aug 2024, Bob Weinand wrote: > On 26.8.2024 19:44:18, Jim Winstead wrote: > > > > Another RFC around process: > > https://wiki.php.net/rfc/web-and-doc-use-not-endorsement > > > > Feedback would be appreciated. My intention is to start voting on > > September 9th unless there is stil

Re: [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)

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On 26/08/2024 18:44, Jim Winstead wrote: Hi, Another RFC around process: https://wiki.php.net/rfc/web-and-doc-use-not-endorsement Feedback would be appreciated. My intention is to start voting on September 9th unless there is still ongoing discussion. Thanks. Jim It seems improbable to

Re: [PHP-DEV] [RFC] Default expression

On 26/08/2024 11:32, Andreas Heigl wrote: Hey folks. Am 26.08.24 um 11:26 schrieb Bilge: On 26/08/2024 10:03, Andreas Leathley wrote: On 24.08.24 18:49, Bilge wrote: For me there is another question. When using interfaces and classes, default values can be introduced, like this: interface Co

Re: [PHP-DEV] [RFC] Default expression

On 26 August 2024 22:27:55 BST, Matthew Weier O'Phinney wrote: >How exactly is this worrisome? Consider this: > >class A { >public function __construct(private LogInterface $logger = new >DefaultLogger()) { } >} > >class ProxiedLogger implements LogInterface { ... } > >

Re: [PHP-DEV] [RFC] Default expression

On 26/08/2024 22:27, Matthew Weier O'Phinney wrote: Again, there are a few lists going around on this thread, and I hope that Bilge is taking notes to add to the RFC, and working with the folks who helped him with implementation to determine what is and is not possible in terms of the grammar s

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024 at 3:45 PM John Coggeshall wrote: > > > On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney < > mweierophin...@gmail.com> wrote: > > > I can see a few others: > > - string concatenation. I might want to prepend or append a string to a > default. > > - fractional or multiplica

Re: [PHP-DEV] [RFC] Default expression

On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney wrote: > > I can see a few others: > > - string concatenation. I might want to prepend or append a string to a > default. > > - fractional or multiplicative application, e.g. for durations/timeouts. > These might require testing for non-zero

Re: [PHP-DEV] [RFC] Default expression

On 26 August 2024 20:27:59 BST, Mike Schinkel wrote: >So, nullable is an equivalent to the union-type concern my discussion with >John Coggeshall uncovered, correct? It's not really anything to do with nulls, or unions. It's somewhat related to "contravariance of input": that it should alwa

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Mon, Aug 26, 2024 at 3:12 PM Bob Weinand wrote: > Thanks for bringing this up - I also suggest that we make this a binary > choice - either we adopt the proposed language or its opposite. > > I.e. a rejection of this should codify that statement in the negative. > > I do in particular reject t

Re: [PHP-DEV] [RFC] Default expression

> On Aug 26, 2024, at 8:28 AM, Rowan Tommins [IMSoP] > wrote: > > On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote: >>> You ask how a library can provide access to that default, and the answer is >>> generally pretty trivial: define a public constant, and refer to it in the >>> parameter def

Re: [PHP-DEV] [RFC] Default expression

On 26/08/2024 15:20, Stephen Reay wrote: Hi, Hi :) I haven't followed the entire thread in depth so I apologise if this was already answered, but I haven't noticed it being mentioned/clarified yet. Don't worry, you're right, this is an important topic that I was still finalising in the past

Re: [PHP-DEV] [RFC] Default expression

On Aug 26 2024, at 2:39 pm, Bilge wrote: > > I like this approach. I'm still not sure I'd want to pursue adding > exclusions, but if we can identify something that's obviously bad and/or > dangerous then we can consider that short list for exclusion. That is much > more compelling than starti

Re: [PHP-DEV] [RFC] Default expression

On 26/08/2024 19:11, Matthew Weier O'Phinney wrote: On Mon, Aug 26, 2024, 12:02 PM Larry Garfield wrote: I recognize that "limiting the allowed expression structures arbitrarily is way harder than it sounds" is a valid argument as well.  At the same time, John C has offered some

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Mon, Aug 26, 2024, at 1:06 PM, Bob Weinand wrote: > Hey Jim, > > On 26.8.2024 19:44:18, Jim Winstead wrote: >> Hi, >> >> Another RFC around process: >> https://wiki.php.net/rfc/web-and-doc-use-not-endorsement >> >> Feedback would be appreciated. My intention is to start voting on September >

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024, 12:02 PM Larry Garfield wrote: > On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote: > > On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP] > > wrote: > >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote: > >> > You're absolutely right, I would be interested to see any via

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

Hey Jim, On 26.8.2024 19:44:18, Jim Winstead wrote: Hi, Another RFC around process: https://wiki.php.net/rfc/web-and-doc-use-not-endorsement Feedback would be appreciated. My intention is to start voting on September 9th unless there is still ongoing discussion. Thanks. Jim Thanks for

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

Hi Jim! On Mon, Aug 26, 2024 at 2:48 PM Jim Winstead wrote: > Hi, > > Another RFC around process: > https://wiki.php.net/rfc/web-and-doc-use-not-endorsement > > Feedback would be appreciated. My intention is to start voting on > September 9th unless there is still ongoing discussion. > > Thanks.

Re: [PHP-DEV] [RFC] Default expression

> From the example you gave it appears that we can have a concrete problem when: > 1. There is a parameter with a default value, > 2. That parameter is type-hinted, > 3. The hinted type is declared as a union type, > 4. An earlier version of the library initialized the default with a value > havi

Re: [PHP-DEV] [RFC] Default expression

Hey Jordi, On 26.8.2024 13:55:52, Jordi Boggiano wrote: One question (sorry if someone already asked, I scanned the thread but it is getting long..): Taking this example from the RFC:     function g($p = null) {         f($p ?? default);     } Could you go one step further and use default by

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote: > On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP] > wrote: >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote: >> > You're absolutely right, I would be interested to see any viable patch >> > that effectively implements a set of restriction

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024 at 12:47 PM Rowan Tommins [IMSoP] wrote: > Another approach that occurred to me was in the executor: rather than > evaluating to the default value immediately, "default" could resolve to a > special value, essentially wrapping the reflection parameter info. Then > when the fu

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024 at 5:36 AM, Jakob Givoni <[ja...@givoni.dk](mailto:On Mon, Aug 26, 2024 at 5:36 AM, Jakob Givoni < wrote > "default" should not evaluate to a value before sending it as an argument to > the function or method. I have no dog in this fight, but I agree with the above. Plus, h

Re: [PHP-DEV] [RFC] Default expression

> On 24 Aug 2024, at 23:49, Bilge wrote: > > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think > some of you might enjoy this one. Hit me with any feedback. > > This one already comes complete with working implementation that I've been > cooking for a l

Re: [PHP-DEV] [RFC] Default expression

On 26/08/2024 12:55, Jordi Boggiano wrote: Hey Bilge, Hi :) On 24.08.2024 18:49, Bilge wrote: New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might enjoy this one. Hit me with any feedback. Great work overall, I'm all for it and even though it's not s

Re: [PHP-DEV] [RFC] Default expression

On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote: >> On Aug 26, 2024, at 3:28 AM, Rowan Tommins [IMSoP] >> wrote: >> I was responding to someone justifying anything and everything the proposal >> allows, because Reflection already allows it. If the feature was "first >> class syntax to access

Re: [PHP-DEV] [RFC] Default expression

On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote: >> You ask how a library can provide access to that default, and the answer is >> generally pretty trivial: define a public constant, and refer to it in the >> parameter definition. > > A global? Really? I didn't say "global", I said "public".

Re: [PHP-DEV] [RFC] Default expression

Hey Bilge, On 24.08.2024 18:49, Bilge wrote: New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might enjoy this one. Hit me with any feedback. Great work overall, I'm all for it and even though it's not something I saw myself using a whole lot, the json_e

Re: [PHP-DEV] [RFC] Default expression

On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP] wrote: > On Mon, 26 Aug 2024, at 10:14, Bilge wrote: > > You're absolutely right, I would be interested to see any viable patch > > that effectively implements a set of restrictions on how `default` may > > be used. Requesting it be done at t

Re: [PHP-DEV] [RFC] Default expression

On Mon, 26 Aug 2024, at 10:03, Andreas Leathley wrote: > interface CompressionInterface > { >     public function compress(string $data, int $level): string; > } > > class GzipCompression implements CompressionInterface > { >     public function compress(string $data, int $level = 4): string >  

Re: [PHP-DEV] [RFC] Default expression

On Mon, 26 Aug 2024, at 10:14, Bilge wrote: > You're absolutely right, I would be interested to see any viable patch > that effectively implements a set of restrictions on how `default` may > be used. Requesting it be done at the parser level was not meant as a > gotcha, that's just how I (with

Re: [PHP-DEV] [RFC] Default expression

> On Aug 26, 2024, at 2:26 AM, John Coggeshall wrote: > The proposal in the RFC creates a new dependency and backward compatibility > issue for API developers that currently does not exist. It is not just > because it allows for non-sensical expressions, but that it allows perfectly > sensical

Re: [PHP-DEV] [RFC] Default expression

On 26/08/2024 08:28, Rowan Tommins [IMSoP] wrote: As far as I can see, nobody has actually justified reading values out in this way, only said it's a side-effect of the current implementation. It's pretty useful for testing. Aside: one of those examples brings up an interesting question: is th

Re: [PHP-DEV] [RFC] Default expression

Hey folks. Am 26.08.24 um 11:26 schrieb Bilge: On 26/08/2024 10:03, Andreas Leathley wrote: On 24.08.24 18:49, Bilge wrote: For me there is another question. When using interfaces and classes, default values can be introduced, like this: interface CompressionInterface {     public function co

  1   2   3   4   5   6   7   8   9   10   >