Re: [PHP-DEV] Stricter requirements for libxml
On 14/05/2024 11:36, Derick Rethans wrote: > On Fri, 10 May 2024, Niels Dossche wrote: > >> Hi internals >> >> Libxml is used as the underlying library for many PHP extensions. >> Interestingly, libxml can be built with supports for various features >> disabled. >> E.g. you can build libxml without XPath, Schemas, HTML, ... support. >> In that case, these features are unavailable in PHP. E.g. some classes may >> not be defined or functions may emit a warning instead of performing an >> action. >> >> I'm thinking of proposing an RFC that puts stricter requirements on libxml >> at build time. >> That would make such features a requirement during PHP's build process. >> This will simplify maintenance and will also make sure that users can rely >> on these functionalities to always be available. >> >> Please let me know what you think. > > That seems sensible. Did you find any Linux distribution that actively > disables these features, or is this a "just in case" kind of change? > > cheers, > Derick I am not aware of a distro that disables these features. This is a "just in case" thing. The fact that I didn't find one is also a motivation to make this change: why should we make the code more complicated to support a configuration that doesn't seem to be used? :) Kind regards Niels
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On 11-5-2024 16:43, Gina P. Banyard wrote: On Thursday, 9 May 2024 at 15:17, Jorg Sowa wrote: > I don't think there are any other "functions" like this. What about list(), isset(), print(), echo(), require(), include(), unset(), empty()? We use them the same way as functions, but those are not real functions. list() (and array()) may look like functions but do not behave like one as they affect the current scope by setting various variables. isset()/empty()/unset() require to work with undefined variables and have deeply ingrained behaviour within the engine, so making them simple functions is not as much of a "trivial" change. print, echo, include(_once) and require(_once) do not mandate their "argument" to be passed within parenthethis, so making them functions does not simplify the lexer/parser nor removes them as keywords. Also I don't know the last time I've used those language constructs "like a function". Seeing this list, makes me wonder: what about eval() ?
Re: [PHP-DEV] Stricter requirements for libxml
On Fri, 10 May 2024, Niels Dossche wrote: > Hi internals > > Libxml is used as the underlying library for many PHP extensions. > Interestingly, libxml can be built with supports for various features > disabled. > E.g. you can build libxml without XPath, Schemas, HTML, ... support. > In that case, these features are unavailable in PHP. E.g. some classes may > not be defined or functions may emit a warning instead of performing an > action. > > I'm thinking of proposing an RFC that puts stricter requirements on libxml at > build time. > That would make such features a requirement during PHP's build process. > This will simplify maintenance and will also make sure that users can rely on > these functionalities to always be available. > > Please let me know what you think. That seems sensible. Did you find any Linux distribution that actively disables these features, or is this a "just in case" kind of change? cheers, Derick
Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath
Hi all, Regarding some of the points, I have decided to address them as th follow-up RFC. Further discussion will take place in a separate thread. Regards, Saki
[PHP-DEV] Re: [RFC] [Discussion] #[\Deprecated] attribute again v1.3
On Thu, May 2, 2024 at 1:00 PM Benjamin Außenhofer wrote: > > > On Tue, Apr 23, 2024 at 3:27 PM Benjamin Außenhofer > wrote: > >> Hi internals, >> >> My PR for #[\Deprecated] attribute was in hibernation for a long while >> now and after some off-list discussion a few weeks ago I have decided to >> revisit it and asked Tim to help me out with the work. >> >> Tim has cleaned up the PR quite a bit and also worked in additional >> features such as #[Deprecated] support in stub generation. >> >> While there are still some small todos, at this point we want to restart >> the discussion about the RFC for inclusion in 8.4: >> >> RFC: https://wiki.php.net/rfc/deprecated_attribute >> PR: https://github.com/php/php-src/pull/11293 >> Old discussion: https://externals.io/message/112554#112554 >> >> Let me know about your questions and feedback. >> >> greetings >> Benjamin >> > > We have updated the RFC and PR to include #[Deprecated] on class constants > and enum cases as this is something the engine already supports for > internal class constants. > > This does not include support for non-class based constants, because they > don't have support for attributes at the moment and also only recently got > reflection support (for 8.4). > > We are planning to work on adding $since next and get back to the list > once that is finished. > The $since implementation is now added to the RFC and to the PR. We decided to make this a secondary voting choice, while there are use-cases for it in php core for doc rendering, other ways of doing the same thing are also available and given userland frameworks stated different requirements maybe its better left for userland to implement.
