Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, 22:14 Gunnard engebreth wrote: > > On 4/11/23 3:09 PM, Good Guy wrote: > > On 08/04/2023 19:36, Stephan Soller wrote: > >> > >> > >> A few days ago I migrated a project from PHP 7.1 to 8.2 and the > >> amount of > >> deprecations and fatal errors spooked me a bit (details below if you're > >> interested). That got me wondering about the long-term stability of > >> PHP (as in > >> language and API breaks) and I looked at the RFCs. I got the > >> impression that > >> static typing has a lot of traction now and I have no idea of what > >> the fallout > >> might be of changing a dynamically typed language into a statically > >> typed one. > >> Also API breaks seem to become more frequent (e.g. utf8_decode). I > >> stumbled > >> across the language evolution RFC proposals but it seems that > >> approach was > >> abandoned. > > > > I think the php focus has shifted from its original ethos. PHP was > > designed to be a tool to access sql databases and so the language was > > quite simple. > > > > Now php has become so difficult that people are asking what is the > > point pf PHP when programming languages such as c# or C or C++ or JS > > can do everything. It is difficult to learn these languages but so is > > PHP because it is becoming more like a desktop programming language. > > Might as well spend time learning main stream programming languages. > > > > PHP should focus on one thing and one thing only and that is to be the > > simplest tool for sql servers, mainly MySQL but also try supporting > > MS-SQL and PL-SQL (Oracle's premium database system). > > > I think this thread's focus has shifted from its original ethos... > > i'll see myself out ;) > Touché. This was just too classy of them not to acknowledge.
Re: [PHP-DEV] Future stability of PHP?
On 4/11/23 3:09 PM, Good Guy wrote: On 08/04/2023 19:36, Stephan Soller wrote: A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of deprecations and fatal errors spooked me a bit (details below if you're interested). That got me wondering about the long-term stability of PHP (as in language and API breaks) and I looked at the RFCs. I got the impression that static typing has a lot of traction now and I have no idea of what the fallout might be of changing a dynamically typed language into a statically typed one. Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled across the language evolution RFC proposals but it seems that approach was abandoned. I think the php focus has shifted from its original ethos. PHP was designed to be a tool to access sql databases and so the language was quite simple. Now php has become so difficult that people are asking what is the point pf PHP when programming languages such as c# or C or C++ or JS can do everything. It is difficult to learn these languages but so is PHP because it is becoming more like a desktop programming language. Might as well spend time learning main stream programming languages. PHP should focus on one thing and one thing only and that is to be the simplest tool for sql servers, mainly MySQL but also try supporting MS-SQL and PL-SQL (Oracle's premium database system). I think this thread's focus has shifted from its original ethos... i'll see myself out ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 08/04/2023 19:36, Stephan Soller wrote: A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of deprecations and fatal errors spooked me a bit (details below if you're interested). That got me wondering about the long-term stability of PHP (as in language and API breaks) and I looked at the RFCs. I got the impression that static typing has a lot of traction now and I have no idea of what the fallout might be of changing a dynamically typed language into a statically typed one. Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled across the language evolution RFC proposals but it seems that approach was abandoned. I think the php focus has shifted from its original ethos. PHP was designed to be a tool to access sql databases and so the language was quite simple. Now php has become so difficult that people are asking what is the point pf PHP when programming languages such as c# or C or C++ or JS can do everything. It is difficult to learn these languages but so is PHP because it is becoming more like a desktop programming language. Might as well spend time learning main stream programming languages. PHP should focus on one thing and one thing only and that is to be the simplest tool for sql servers, mainly MySQL but also try supporting MS-SQL and PL-SQL (Oracle's premium database system). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Future stability of PHP?
Den 2023-04-08 kl. 20:36, skrev Stephan Soller: Hello, I'm sorry if this isn't the correct mailing list for that discussion but I couldn't find a more appropriate one where people actually know how the wind is blowing. A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of deprecations and fatal errors spooked me a bit (details below if you're interested). That got me wondering about the long-term stability of PHP (as in language and API breaks) and I looked at the RFCs. I got the impression that static typing has a lot of traction now and I have no idea of what the fallout might be of changing a dynamically typed language into a statically typed one. Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled across the language evolution RFC proposals but it seems that approach was abandoned. Is there a way to tell which APIs and language features will be stable and which might get changed or removed in the future? That way I could restrict myself to a stable subset for long-running projects (5 to 10 years). But I realize that such guarantees are difficult (or contra productive) when a language is in flux and I can understand if no one wants to do something like that. Some of my projects run for 5 to 10 years, in one case even 20 years. Usually without or with very little code changes. My usual tool set for web projects like that is plain PHP, HTML, CSS and JS. Everything without any frameworks or unnecessary libraries and kept as simple as possible. If possible I just use builtin and stable APIs and usually end up without any or with just one or two dependencies (e.g. PDF generation). This isn't pretty and I end up trading a bit of productivity for long-term stability. I know this is quite an unusual approach, especially in todays web development world. But I've been developing stuff for over 20 years and in most cases I have to maintain my own code (my first PHP project was about 20 years ago). Without that somewhat unusual focus on stability I would spend my whole time updating existing code and couldn't get anything new done. And let's face it, in most situations you don't need the perfect tool, just something that gets the job done reliably (e.g. sending a query to a database and process the result). So I guess that is my usecase for PHP: A stable base for long-lasting and very low maintenance server-side code. The recent migration made me question that assumption, though. Is this still something that makes sense in your opinion or would you recommend to avoid using PHP for that? A project like PHP is the result of a lot of work from many different people and people, opinions and priorities change over time. The direction of PHP is determined by those who work on it and that's a good thing. I just want to avoid using the wrong tool for the job as this can quickly spiral into a lot of unnecessary complexity and (in a somewhat best case) end in a rewrite a few years later to stop the spiral. I routinely rely on PHP features that are not often talked about (read on sexy or fashionable) to greatly simplify my code: The alternate syntax for control structures as a lightweight template system, implicit type conversions, streams, SimpleXML, a DOM parser that can actually parse real-world HTML, PDOs and so on. PHP has a lot of small nuggets that make it a pretty useful toolbox if you don't overdo it. But did I overdo it? What I didn't realize before was the extend to which I relied on the stability of APIs and core extensions listed in the PHP manual. What will end up on the chopping block in the next few years? Can I rely on the alternate syntax for control structures? Will streams go since HTTP 2 and 3 made a mess of the whole HTTP protocol? I'm note sure how to evaluate the current situation. Hence the post. Migration details for those who're interested: I had PHP pegged as a dynamic language at it's core so I've used techniques like duck typing and dynamic properties here and there when they were the best compromise for simplicity and code locality. This is nothing you would use in large or inexperienced teams but for a lot of small stuff this can keep code simple (it it doesn't amount to more than a few hundred lines). Sometimes I let projects grow organically like that over a few years until we consolidate parts that became to complex once the usecases became clear. Unfortunately this backfired on me during a recent migration. The amount of deprications and out right fatal errors caught me off guard. Dynamically extending objects got deprecated in PHP 8 except for stdClass and the AllowDynamicProperties attribute which sounds reasonable. Unfortunately I ran right into the corner case of attaching dynamic properties to a Generator which caused a fatal error. The rest of the code then used duck typing to work with those properties (basically just isset() checks that use the additional information if
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, at 4:32 PM, Jeffrey Dafoe wrote:
> Can you expand a bit more on your use-case?
>
> We have a lot of classes, a small portion of which use dynamic
> properties, but we do not necessarily know which ones do. It’s
> different than, for example, a change to the count function. We can
> search for all instances of “count” but not for dynamic properties. I’m
> unsure if it’s practical to run deprecations on in prod and our test
> suite, although substantial, doesn’t cover all code paths.
Tools like PHPStan and Psalm can do a pretty good job of finding all dynamic
property usage for you, without needing to write a test suite for it. They'll
treat them as an error, but it should give you a good sense of where to add the
attribute.
It won't be perfect, but it will probably catch the lion's share of them unless
you're doing very dynamic things. ($this->{$foo[$bar]} = 5, or stuff like
that.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] PHP Technical Committee
On Tue, Apr 11, 2023, at 6:02 PM, Björn Larsson via internals wrote: > Den 2023-04-07 kl. 12:58, skrev Jakub Zelenka: >> Hello, >> >> Here is a proposal for an introduction of the PHP Technical Committee: >> >> https://wiki.php.net/rfc/php_technical_committee >> >> The main purpose of this RFC is to have better decision process when >> technical conflicts between developer arise. >> >> This was created in collaboration with other people involved in PHP core >> development and the PHP Foundation. Larry has done a lot of work in >> rewording the text and he is also a co-author of this RFC. >> >> Feel free to comment here or if you have just some wording suggestions >> there is also a PR in my util repository for easier collaboration on the >> text: https://github.com/bukka/php-util/pull/1 . So feel free to comment / >> send suggestion there as well. >> >> Regards >> >> Jakub >> > I think this is a very good initiative, so good luck with it! > > Question: > - Is this something that could be used to point out general areas for > improvement of PHP, e.g. like a roadmap/wishlist for 9.0? That's not really the intent here. It's possible/likely that people elected to the TC will "carry more weight" in any discussions about roadmaps, but there's a chicken-and-egg question there as well. (The kind of people that would get elected are probably the kind that would be listened to.) There's no plans in this RFC to change how feature development works. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] PHP Technical Committee
Den 2023-04-07 kl. 12:58, skrev Jakub Zelenka: Hello, Here is a proposal for an introduction of the PHP Technical Committee: https://wiki.php.net/rfc/php_technical_committee The main purpose of this RFC is to have better decision process when technical conflicts between developer arise. This was created in collaboration with other people involved in PHP core development and the PHP Foundation. Larry has done a lot of work in rewording the text and he is also a co-author of this RFC. Feel free to comment here or if you have just some wording suggestions there is also a PR in my util repository for easier collaboration on the text: https://github.com/bukka/php-util/pull/1 . So feel free to comment / send suggestion there as well. Regards Jakub I think this is a very good initiative, so good luck with it! Question: - Is this something that could be used to point out general areas for improvement of PHP, e.g. like a roadmap/wishlist for 9.0? Regards //Björn L -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Monday 10 April 2023 14:17:04 (+02:00), G. P. B. wrote: > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism [...] > > The existing SPL autoloading functions would become aliases to the new Core > ones and will continue to work without any migrations needing to be > performed. > > Hope to hear your opinions about this! Thanks for taking the time for this, I only quickly skimmed over it, an insightful reading already. What I wondered about and which made me writing a reply on the list is in retrospect of the times class autoloading came in, which is also closer to the time when namespaces were introduced. It was the latter which brought us `class_alias()` [0] and I've used it often in code migrations (is 8.3 the new 5.3? would be easy to remember.). So I'd love to see some commentary on a `function_alias()` if now function autoloading is considered to come in, as I can imagine this has similar effects for how you'd like to namespace PHP code with the new, better functionality of function autoloading and access to an alias table from PHP "userspace" I'd consider helpful then. Best, -- hakre [0]: https://www.php.net/class_alias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] Future stability of PHP?
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying. Yes, we have a _lot_ of classes. Also multiple versions of Zend framework that we backport to. However, I see in a subsequent email that this is in preparation for improvements, which makes it more tolerable. To clarify; Are you saying that you have a _lot_ of classes _which make use of dynamic properties_? A class where properties are predefined is unimpacted by this. stdClass is also unimpacted (as it implicitly has allowdynamicproperties). The only classes you should need to add the attribute to are ones where you're using them, essentially, as typed associative arrays. I'm surprised if that's what you have, because it seems like a lot of extra effort to give names to what are essentially anonymous structures. The advantage of providing a name should be that you get to know what properties will be present (and perhaps that the values therein are validated or typed themselves). Can you expand a bit more on your use-case? We have a lot of classes, a small portion of which use dynamic properties, but we do not necessarily know which ones do. It’s different than, for example, a change to the count function. We can search for all instances of “count” but not for dynamic properties. I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths. I’d probably summarize our use case for dynamic properties as “old codebase and dynamic properties were OK”. Our system was originally in Perl, so the initial dev team probably felt at home with dynamic properties coming from Perl objects. But again, after reading others’ comments stating that this is part of an effort to improve some aspect of PHP classes, we can live with the change. I was recently looking at the Perl 5.x repo and was surprised at the amount of activity. There may be some small takeaway (like, literally a small takeaway, not in the “small meaning big” sense) in how the 5.x community has seemingly flourished, especially considering the failure of Perl 6. -Jeff (and I apologize for the mauled quoting... Outlook, annoying mailing lists since forever)
Re: [PHP-DEV] Future stability of PHP?
> Can you expand a bit more on your use-case? Here are some things I've deliberately used dynamic properties for: - development proxies (production uses compiled proxies) for remote objects [can use attribute or magic functions] - visitor pattern when hacking on parser packages [in PHP 9, "hacking" will be more complex if underlying package doesn't support dynamic properties] - "tagging" objects [can use weak maps now] - deserialization of user-submitted types to a base class [can just 'decorate' a stdClass] In brackets, I listed the 'solution' for avoiding dynamic properties, but FWIW, having dynamic properties available made it far easier to create 'POC-style' code that could be refactored/rewritten. I personally never saw a bug resulting from dynamic properties, but I might have just been lucky. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Property Hooks Discussion
> Ah, I see now what you meant, Robert. This already doesn't hold.
>
> class Foo {
> public int $prop;
> }
> $foo = new Foo();
> $value = '42';
> $foo->prop = $value;
> var_dump($value === $foo->prop);
> // false
I don’t know if this has been closed or discussed further in private but this
has just came to me:
This could be solved with some kind of an operator overloading for the
property, but then it would just raise more questions to answer / problems to
solve. But the problem mentioned above can well happen even if one would use
the same types.
class Baz {
public function clone(): self {
// create new instance into which I copy all my properties.
}
}
class Foo {
public Baz $val {
beforeSet(Baz $new) => $new->clone();
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Modules
On Tue, Apr 11, 2023, 11:32 AM Larry Garfield wrote: > But the same people will still complain just as loudly whenever that is, > because they haven't done anything about it for the past 17 years so > they're not going to now. > Do you know that for a fact or should this statement be classified as, and I'm quoting here, "BS"? >
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 9:29 AM Jeffrey Dafoe wrote: > Essentially the same thing here. Removal of dynamic properties will be the > next big one for my team. It's the deprecations that hit huge swaths of > code without really offering much benefit that are annoying. > > Yes, we have a _lot_ of classes. Also multiple versions of Zend framework > that we backport to. However, I see in a subsequent email that this is in > preparation for improvements, which makes it more tolerable. > > To clarify; Are you saying that you have a _lot_ of classes _which make use of dynamic properties_? A class where properties are predefined is unimpacted by this. stdClass is also unimpacted (as it implicitly has allowdynamicproperties). The only classes you should need to add the attribute to are ones where you're using them, essentially, as typed associative arrays. I'm surprised if that's what you have, because it seems like a lot of extra effort to give names to what are essentially anonymous structures. The advantage of providing a name should be that you get to know what properties will be present (and perhaps that the values therein are validated or typed themselves). Can you expand a bit more on your use-case? -Sara
Re: [PHP-DEV] Future stability of PHP?
Original message From: Andreas Leathley Date: 2023-04-11 07:19 (GMT-08:00) To: internals@lists.php.net Subject: Re: [PHP-DEV] Future stability of PHP? On 11.04.23 15:56, Jeffrey Dafoe wrote:>> So turn off the deprecation warnings for now. They're just a heads up that>> behaviour is going to change in the future, with PHP 9. I doubt you'd prefer not to be aware of the change well in advance.> Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit.Removing dynamic properties has multiple benefits - from avoidingtypos/mistakesAs a heavy php user but not core contributor... removal of dynamic properties is just simply fantastic. Dynamic properties hide so many horrors and were the cause of the singular most difficult to debug issue I've ever dealt with that was easily replicated.NickNick Dickinson-Wilde he/him [EN]| il/lui [FR] NickDickinsonWilde.ca | 250-893-3080 (cell) (7am-10pm) - Pacific Date Time Personal: Twitter, GitHub, Drupal.org. ---
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 9:18 AM Robert Landers wrote: > > You can add `#[AllowDynamicProperties]` to classes where you want to > allow > > dynamic properties. > > I don't think that will work in PHP 9? > > In Niki's earliest draft, he wanted to completely remove dynamic properties from *default* class handlers in 9.0, as this would simplify the most common use-case for classes and objects and improve their runtime efficiency. Even in this case, however, the stdClass specialization would have dynamic properties implemented in a way which would allow an escape hatch for user classes via extending stdClass. We wound up with the attribute approach instead, which means that the logic for dynamic properties, as well as the allocation overhead, still has to exist in all userland classes. All approaches however, came with stdClass working as expected out of the box, and a low-effort, forward-compatible escape hatch for those rare cases where dynamic properties are needed on custom classes. This is because PHP's dedication to stability IS, AND REMAINS, steadfast and fanatical. -Sara
Re: [PHP-DEV] PHP Modules
On Tue, Apr 11, 2023, at 1:40 AM, Michael Morris wrote: > This will be long. I've read over the Future Stability thread and taken it > in, and decided to mull over an idea I touched on over a decade ago that I > think might help. Also, in the interceding years the JavaScript community > has overcome a compatibility issue using this technique, so we might do the > same. > > The crux of the stability problem is the need to update functions without > introducing a BC break. Adding in new features without removing old ones > also makes it confusing to incoming programmers as to what to use. > > I propose PHP Modules to hold new features. The existing namespace and > functions would be left alone. Existing files would also not be affected - > the behavior of PHP modules would be entirely opt in. > > They would work similar JavaScript modules - they would use the import > keyword and the include, require, include_once and require_once directives > would pitch an error if used in a PHP module. PHP Modules also would not > parse as templates at all - no opening that will be a headache for IDE makers, but it's not insurmountable). > > PHP would have a new ini directive to use them similar to the "type": > "module" directive that npm uses now. If that ini directive isn't set, php > files would be handled as they always have. mphp files would always be > handled as php modules though and lphp (legacy php) would always be handled > as legacy php. > > I expect some objection to file extensions affecting parsing behavior, but > over the last 5 years this approach has worked for the JavaScript community > with cjs, mjs and js files. Here the existing php, phtml, php3, php4 > extensions are handled as the directive instructs them to be handled, only > the two new never before used extensions of lphp and mphp would do their > thing. > > In a PHP module a function has to be imported before it's used with a > handful of exceptions. The root namespace of php modules is utterly empty, > or as close to empty as makes sense. > > The existing functions would be gathered into modules so that they can be > imported. While this is done the headache inducing inconsistencies like > haystack, needle for strings and needle, haystack for arrays can be > addressed. I really don't care which is adopted, but having one order for > this language wide would be nice. Also, decide once and for all - camelCase > or underscore_case. > > The above alone would be massive. Maybe it's impossible given the number > of devs available. The one thing modules can do that the current system > cannot is allow devs to pick which version of the module to use: > > import split from 'php.mb' // imports the mbsplit() function from the > current version of PHP. > > Say the mb module gets some bc breaks. We can put them into a new module so > that the behavior is once again opt in. The strongest way to do this is to > make composer a 1st class part of the language and let it specify the > version of the module that is loaded. > > The import command would be able to pull from the file system or from the > import map as JavaScript does currently. For ease of dev headaches I'd > recommend hewing to the JS model as close as possible as it is proven, and > many of us already use it anyway when developing browser code. > > I hope this helps, or at least spurs a conversation to come up with > something to address this issue. The main question, in my mind, is what problem is this solving. From the description here, it sounds like you're targeting "clean up inconsistencies in the stdlib", which could be done much more easily by putting new versions in a namespace, something that's been discussed many times. (And usually run into a wall of how much redesigning we should do in the process, and then people lose interest.) The previous times modules have been proposed, the big selling point was module-level visibility. Eg, object properties or methods that are visible to other classes/functions in the same module, but not outside of it. That's a problem space that would be solved by modules, which namespaces cannot solve. (Whether worth the effort or not is a separate question.) Most of the BC discussion right now (and generally) isn't about function or class redesign. It's about changes in language syntax behavior, such as undefined-var/key being promoted from Notice to Warning (8.0), or making dynamic properties opt-in via an attribute, or having stdlib functions react to null parameters the same way as userspace functions, etc. Regardless of whether you consider those good or bad changes, they're not the sort of thing that modules would solve. There has been discussion in the past of adding more declare statements to allow opt in/out of certain changes, like declare(warn_on_missing_var=1) or something. To whatever extent that's feasible, it's less work than doing it that way (per-file) than introducing a module system to handle that
RE: [PHP-DEV] Future stability of PHP?
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying. -Jeff You can add `#[AllowDynamicProperties]` to classes where you want to allow dynamic properties. Yes, we have a _lot_ of classes. Also multiple versions of Zend framework that we backport to. However, I see in a subsequent email that this is in preparation for improvements, which makes it more tolerable. -Jeff
Re: [PHP-DEV] Future stability of PHP?
> Please double-check the source before sending questions like that to the > list, since that information is easilly accessible Sorry, I'll refrain from asking stupid questions in the future. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, 17:18 Robert Landers wrote: > > You can add `#[AllowDynamicProperties]` to classes where you want to > allow > > dynamic properties. > > I don't think that will work in PHP 9? > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php Please double-check the source before sending questions like that to the list, since that information is easilly accessible: https://wiki.php.net/rfc/deprecate_dynamic_properties Nothing of the sort is happening. The attribute is specifically to mark classes that can use dynamic properties going forward.
Re: [PHP-DEV] Future stability of PHP?
Hi On 4/11/23 16:18, Robert Landers wrote: You can add `#[AllowDynamicProperties]` to classes where you want to allow dynamic properties. I don't think that will work in PHP 9? As per the corresponding RFC at https://wiki.php.net/rfc/deprecate_dynamic_properties#proposal: Classes marked with #[AllowDynamicProperties] as well as their children can continue using dynamic properties without deprecation or removal. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 11.04.23 15:56, Jeffrey Dafoe wrote: So turn off the deprecation warnings for now. They're just a heads up that behaviour is going to change in the future, with PHP 9. I doubt you'd prefer not to be aware of the change well in advance. Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit. Removing dynamic properties has multiple benefits - from avoiding typos/mistakes (which before were completely silent) from being able to refactor objects in PHP in general (after PHP9) to be more efficient. The RFC (https://wiki.php.net/rfc/deprecate_dynamic_properties) details those benefits quite well, if there were no benefits it would hardly have passed. This is one of the no-brainer changes for me, as the upgrade path with the attribute is so easy and there are so many benefits. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
> You can add `#[AllowDynamicProperties]` to classes where you want to allow > dynamic properties. I don't think that will work in PHP 9? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 3:33 PM Jeffrey Dafoe wrote: > > was something introduced in a time that the code being written using it > has > > 100% test coverage and static analysers protecting it. It's easier for > me to deal > > with any BC breaks of PHP 7.1 or higher than it is to deal with > deprecations of > > PHP 5.6 or lower. > > Essentially the same thing here. Removal of dynamic properties will be the > next big one for my team. It's the deprecations that hit huge swaths of > code without really offering much benefit that are annoying. > > -Jeff > You can add `#[AllowDynamicProperties]` to classes where you want to allow dynamic properties.
RE: [PHP-DEV] Future stability of PHP?
> So turn off the deprecation warnings for now. They're just a heads up that > behaviour is going to change in the future, with PHP 9. > > I doubt you'd prefer not to be aware of the change well in advance. Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit. It's only a tiny portion of the language changes, though, and I mention it just for awareness, as we are **VERY** appreciative of the work everyone puts into the PHP project. I know it's a thankless task. -Jeff
RE: [PHP-DEV] Future stability of PHP?
On 11 April 2023 14:33:27 BST, Jeffrey Dafoe wrote: >> was something introduced in a time that the code being written using it has >> 100% test coverage and static analysers protecting it. It's easier for me to >> deal >> with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations >> of >> PHP 5.6 or lower. > >Essentially the same thing here. Removal of dynamic properties will be the >next big one for my team. It's the deprecations that hit huge swaths of code >without really offering much benefit that are annoying. So turn off the deprecation warnings for now. They're just a heads up that behaviour is going to change in the future, with PHP 9. I doubt you'd prefer not to be aware of the change well in advance. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] Future stability of PHP?
> was something introduced in a time that the code being written using it has > 100% test coverage and static analysers protecting it. It's easier for me to > deal > with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations > of > PHP 5.6 or lower. Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying. -Jeff
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 11 April 2023 13:21:08 BST, Mark Baker wrote: >We have the special constants like \MyNamespace\MyClass::class. Would you >envisage (or is there value in) equivalent constants like >\MyNamespace\MyFunction::function? This has come up before, but there are two things about ::class to bear in mind: 1) It has nothing to do with classes. It just means "resolve namespaced name", and doesn't care what string appears on its left-hand side. 2) It is calculated (except in a few specific cases) at compile-time, based entirely on the contents of the current file, with no relationship to autoloading or what is defined elsewhere. That's very different from function (and constant) lookups, which happen at run-time, and specifically check whether a function is defined in the current namespace before falling back to the global one. In other words, the value of foo::function would be dependent on runtime state in a way that Foo::class is not. Meanwhile, the main use case for such a syntax - getting a reference to use as a callback - is now well served by the first class callable syntax my_function(...) Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 11 April 2023 13:01:08 BST, Dan Ackroyd wrote:
>On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>>
>> Similarly, I think it should be possible to "unpin" a function
>> lookup with a later definition,
>
>Can you say what the technical justification for that is?
Perhaps "should" is too strong, but I would find it surprising if *using* a
global function made it impossible to *define* a namespaced one.
As I said in my previous message, there is a fundamental difference between
caching of unprefixed name lookups, and actual function definitions. The
current fallback and caching can always be skipped by using a fully qualified
name.
If additional caching is achieved using a dummy entry in the function table, a
real entry for that function should be able to evict it, so that a
fully-qualified function name can still be used.
>Lots of things are possible, but I'd strongly prefer to have that be a
>separate discussion, which it's listed as a future scope:
>https://wiki.php.net/rfc/core-autoloading#higher_performance_through_maps
>
>If nothing else, it's going to take people time to figure out how they
>are going to organise code that is 'just' a bunch of functions.
I'm not talking about full mapping from name to file, or about functions
specifically, but about a lot of existing autoloaders beginning with
boilerplate like "if ( ! str_starts_with('Acme\\Foo\\') ) { return; }", and
then whatever logic is used for loading Acme\Foo classes. If the core
implementation can perform that check, it can skip the context switch to
userland code.
That's a benefit to the class autoloading anyway, but I'd be very surprised if
function autoloaders looked any different, because that separation of ownership
is pretty much what namespaces are *for*.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 5:40 AM Alex Wells wrote: > On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > >> I don't want to use those weird stuff, but I'm >> doing the best I can to replace every single line of old code that has >> been >> written in an era that "best practices for PHP development" were not what >> you and I know today. >> > > I still do not understand why you're expecting the whole PHP project to > put in enormous efforts to keep the backwards compatibility and solve your > problems (temporarily) instead of you doing so. What's stopping you from > using the last supported PHP version by that codebase and fixing or, worst > case scenario, rewriting it if you wish, while on that (non latest) PHP > version? What causes the desperation to update to the latest PHP? Is it new > features or security fixes, or both? > I don't *expect* the whole PHP project to do anything. Let me start by bringing up a quote: > [...] your thoughtful insight on how language changes [...] will help shape proposals in a much more significant way. Disclaimer: This quote is taken out of context, the original message can be found here: https://externals.io/message/110936#110937 As I've mentioned here before, I've seen a few folks bring up the message that I see on this quote as: Voting rights are not necessary to contribute to PHP Internals. PHP is an extremely large ecosystem and bringing community/user voices to internals can greatly help developers understand how the language is being used and how proposals can be shaped to help address concerns that are made aware. I'm not voicing my concerns in the hopes of making my problems your problems and that the PHP core developers should fix it for me. I have been going through a rewrite for the last 6 years and I expect to be done with it in the next 5. Every year we need to go back to the legacy spaghetti and upgrade it for security reasons. It's busywork and adds no real value to us. We still do it and we will keep doing it no matter what. But in the course of doing so, I lost coworkers to Typescript with a reasoning that it doesn't make sense to rewrite our product in a language that will keep breaking the codebase constantly. I'm not here to discuss the merits of their decision because if I 100% agreed with that decision, I wouldn't be here, I would be long gone and developing Typescript fulltime by now. But in my little bubble, losing highly talented PHP developers to Typescript has been a recurring situation and that loss of community members saddens me. So if you could please read my message as "here's what has happened in a small corner of the PHP community that is directly related to what OP has mentioned at the start of the thread (PHP stability). Maybe this is not new information to any of you here and there's nothing that can be improved on it unless someone drops 8 digits of money on the PHP project. Maybe that is a price that PHP has been willing to pay to keep on doing what it currently is doing. Or maybe there are some interesting things that can be taken into consideration. Do what you will with my participation. The only expectation I had when I joined this discussion was respect and that was almost completely met. -- Marco Deleu
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Tue, 11 Apr 2023 at 08:14, Michał Marcin Brzuchalski wrote: > > Can we improve the RFC with a short description of issues on SPL autoload > this RFC tries to address? Sure, if you want to propose some clearer words than these: "The spl_autoload_register() does not become an alias for autoload_register_class() to preserve BC by continuing to return true, allowing it to register the default SPL autoloader, and accepting the ignored second parameter, but they are both forwarded to an identical internal implementation." The RFC could always be improved. But the main reason to separate the autoload functions from the SPL, is that imo autoloading probably should never have been part of SPL. At the time, new functionality was dumped into SPL as a convenient place to put stuff. At some point (probably after distributing extensions becomes a lot easier) moving the SPL away from PHP core might be a sensible thing to do, as the SPL has some 'not great' design choices that are pretty impossible to solve: https://phpopendocs.com/rfc_codex/spl_summary Or at least impossible to solve while the release cycle of the SPL is tied to that of PHP itself. But autoloading would need to stay as part of PHP core itself. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
> > We have the special constants like \MyNamespace\MyClass::class. Would > you envisage (or is there value in) equivalent constants like > \MyNamespace\MyFunction::function? > If anything, I would suggest renaming the existing constant to something more meaningful. There is no point in adding ::function because that would just be an additional confusing alias for the same thing. Doing strpos::class works just fine, but is semantically incorrect.
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 10/04/2023 14:17, G. P. B. wrote: Dan and I would like to propose a new core autoloading mechanism that fixes some minor design issues with the current class autoloading mechanism and introduce a brand-new function autoloading mechanism: https://wiki.php.net/rfc/core-autoloading The existing SPL autoloading functions would become aliases to the new Core ones and will continue to work without any migrations needing to be performed. I fully support this endeavour: I've wanted this for such a long time now. A while ago I was pressured into splitting two of my libraries that provided both function and class/method calls, increasing my maintenance workload. This would allow me to combine them again. Looking at all the points that have already been raised, I think Sara sums up well. I also like Rowan's suggestion of a list of namespace prefixes. In particular, you're already considering the use of maps for even better performance, and Constant and Stream autoloading, as possible future enhancements. Constants in particular is something I'd find particularly useful; and my only concern with this is the increased number of functions compared with a single function that accepts a Type argument (as Aleksander suggests). A couple of general questions: Are there any core functions that should never by overloaded (function_exists() perhaps)? We have the special constants like \MyNamespace\MyClass::class. Would you envisage (or is there value in) equivalent constants like \MyNamespace\MyFunction::function? If there is value, how would that tie in with referencing them as Callables in callback functions? -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>
> Similarly, I think it should be possible to "unpin" a function
> lookup with a later definition,
Can you say what the technical justification for that is?
There's reasons why (imo) it's probably wrong, but I don't currently
understand what you would want it for, so want to make sure I don't
miss something in my response.
> This isn't actually true: classes, interfaces, traits, and enums all share
> a symbol table, and thus an autoloader. I don't know of a good name for
> this symbol table, though.
As per the RFC it would probably just be 'type'. When PHP is compiling
some code:
function foo(Bar $bar): Quux { ... }
Before 'Bar' and 'Quux' are loaded, the only thing that is safe to
assume about them is that they are a type, whether that be a class
either with methods or without (also called an interface), or an enum,
or eventually a type alias like `type number = float|int;`.
> Regarding the API, would it be possible to take advantage of nearly
> all autoloaders only being interested in particular namespace prefixes?
Lots of things are possible, but I'd strongly prefer to have that be a
separate discussion, which it's listed as a future scope:
https://wiki.php.net/rfc/core-autoloading#higher_performance_through_maps
If nothing else, it's going to take people time to figure out how they
are going to organise code that is 'just' a bunch of functions.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 11 April 2023 12:16:18 BST, "G. P. B." wrote:
>
>However, we *already* do function pinning which can result in this
>behaviour via the function cache, see the following bug which defines a new
>function via eval():
>https://bugs.php.net/bug.php?id=64346
That's not the same thing - that's pinning *the meaning of an unprefixed name
within a particular scope*, my example was of using *a fully-qualified function
name*, of a function that has never been defined.
Substituting a fully-qualified name in the example from that bug runs the
namespaced function just fine: https://3v4l.org/tReC3
>I am not sure that it calling the global strlen() is that surprising, as it
>is basically aliasing the function \Foo\strlen() to \strlen().
That's the implementation detail that I'm saying should not leak. It is not the
current semantics of function lookups, and I don't think it's desirable
semantics.
>> Similarly, I think it should be possible to "unpin" a function lookup with
>> a later definition, even if no autoloading would be triggered. That is,
>> this should not be a duplicate definition error:
>>
>> namespace Foo;
>> if ( strlen('magic') != 42 ) {
>> function strlen($string) { /* ... */ }
>> }
>>
>
>There are some larger technical issues at play, as mentioned in the
>previous bug.
The above code doesn't currently generate an error, and the function defined is
callable with and without prefix: https://3v4l.org/nPbat
If I understand right, the caching issue is that some uses of unprefixed
strlen(...) might not pick up the new function; but fully qualified uses will
reliably do so.
>That is actually interesting, hadn't thought about taking an array of
>prefixes.
>And yes, every callback call requires a VM re-entry, which is expensive.
>
>Should the prefix be with or without the trailing backlash?
It would probably make sense to follow Composer's lead and require it; their
reasoning seems sound (from https://getcomposer.org/doc/04-schema.md#psr-4):
> Namespace prefixes must end in \\ to avoid conflicts between similar
> prefixes. For example Foo would match classes in the FooBar namespace so the
> trailing backslashes solve the problem: Foo\\ and FooBar\\ are distinct.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
> On Apr 10, 2023, at 07:17, G. P. B. wrote: > > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading At a high level: +1, would vote for again (I think I voted for this last time it came up...) Initial thoughts, mostly based on replies so far: 1/ There's certainly some bike-shedding for the names to do. Good points have already been made and I won't belabor them. 2/ I'm unconcerned by the edge case brought up about load ordering as I feel that having multiple definitions of a single function name in an autoload friendly codebase grouped in files which permit this kind of shenanigans is a technical possibility, but a practical absurdity. Nobody should be designing traps like that. 3/ Pinning concerns me a little, and we should certainly build some strong unittests to validate behavior here, but I'm confident that can be resolved during implementation. 4/ If nothing else, I just look forward to gaining consistency here. autoloading being exclusive to classes has long annoyed me, just not quite to the point of action. :) -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
> I'm saying that the DX for writing extensions is better in other languages. Citation needed. Java's extension API is certainly a hot mess. Python's is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice at first blush, but given that it's closer to an FFI than a proper extension API, shortfalls inevitably show up when you try to do anything complex. I'd also point out that PHP's extension API isn't stagnant. The stub generation improvement of just a few years ago significantly improved the process of writing extensions. > And that these days new products come along and provide extensions for > other languages but not PHP. Which is a problem I can only work around by > writing an extension. Okay. Why is this a problem? This is what's right about OSS. That you can take two things and smush 'em together because you need something from both. > PHP now has FFI which provides an easier way to extend PHP. I have huge > hopes for it - but in my experience it doesn't feel finished. I agree, it's not finished. But the problem there is also the opportunity. OSS works best when people who have an actual need are the ones designing the interfaces and making things better. I don't pay attention to FFI because I can write PHP extensions on a my mobile, while sitting on an island beach and playing board games (true story). I know that's not universally true, but it's why I'm not putting the effort in, because I'll end up building the wrong solution by not truly understanding the requirements (also a true story, take a look at streams sometime). If it feels like FFI is stalled, it's probably because it's "good enough" for the people who got it to this point. The itch is scratched and the need is met. So when I call the state of FFI an opportunity, I'm not saying "code or gtfo" as such is sometime vilified. I'm saying this is an open source project of the purest kind and it really is up to someone to care about a thing enough to put in the work to make it better. And if your reply is, "But I don't know C", then good news! That's another opportunity. PHP is a nice language, but it's not the only one out there. C is a mother language, the payoff on learning just keeps coming around. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
> > As a result of the pinning, function_exists() will return true for
> functions in namespaces that have been pinned to a global function.
>
> The lookup pinning seems like the right way to optimise the
> implementation, but I don't think it should be visible to user code like
> this - a lookup for "strlen" in namespace "Foo" is not the same as defining
> the function "Foo\strlen". Consider this code:
>
> namespace Bar {
> if ( function_exists('Foo\strlen') ) {
> \Foo\strlen('hello');
> }
> }
> namespace Foo {
> strlen('hello'); // triggers name pinning
> }
> namespace Bar {
> if ( function_exists('Foo\strlen') ) {
> \Foo\strlen('hello');
> }
> }
>
> If I'm reading the RFC correctly, the second function_exists will return
> true. I'm less clear if the call to \Foo\strlen will actually succeed - if
> it gives "undefined function", then function_exists is clearly broken; if
> it calls the global strlen(), that's a very surprising side effect.
>
It *should* indeed call the global strlen() but I hadn't actually created
such a test as ... I hadn't thought of doing that.
However, we *already* do function pinning which can result in this
behaviour via the function cache, see the following bug which defines a new
function via eval():
https://bugs.php.net/bug.php?id=64346
I am not sure that it calling the global strlen() is that surprising, as it
is basically aliasing the function \Foo\strlen() to \strlen().
For bonus points, the call to strlen that triggers pinning could be inside
> an autoloader, making even the first function_exists call return true.
>
If it is in the same namespace as the autoloader, then yes. However, if the
autoloader is in Bar then only Bar\strlen() is being aliased to \strlen().
Ilija mentioned this off-list, and I hadn't considered this, but this could
lead to a large increase of symbols being defined in the function symbol
table, as every nonqualified call (either by using the "use" statement, or
writing the full FQN) will get aliased to a global function and take an
entry in the symbol table.
> Similarly, I think it should be possible to "unpin" a function lookup with
> a later definition, even if no autoloading would be triggered. That is,
> this should not be a duplicate definition error:
>
> namespace Foo;
> if ( strlen('magic') != 42 ) {
> function strlen($string) { /* ... */ }
> }
>
There are some larger technical issues at play, as mentioned in the
previous bug.
The function cache will pin the call and there is no way of unpinning it. I
tried looking into fixing this, but it turns out to be too complicated
(/impossible?).
More so, disabling the function cache is a massive performance penalty.
As such, the RFC follows the current de facto behaviour.
> > The use of the word class in the API is currently accurate
>
> This isn't actually true: classes, interfaces, traits, and enums all share
> a symbol table, and thus an autoloader. I don't know of a good name for
> this symbol table, though.
>
They do share a symbol table indeed but using class is probably the least
confusing one.
> Regarding the API, would it be possible to take advantage of nearly all
> autoloaders only being interested in particular namespace prefixes?
>
> Currently, every registered autoloader is run for every lookup, and most
> immediately check the input for one or two prefixes, and return early if
> not matched. I suspect this design is largely because autoloading came
> before namespaces, so the definition of "prefix" wasn't well-defined, but
> going in and out of userland callbacks like this is presumably rather
> inefficient.
>
> Perhaps the "register" functions should take an optional list of namespace
> prefixes, so that the core implementation can do the string comparison, and
> only despatch to the userland code if the requested class/function name
> matches.
>
That is actually interesting, hadn't thought about taking an array of
prefixes.
And yes, every callback call requires a VM re-entry, which is expensive.
Should the prefix be with or without the trailing backlash?
Best regards,
George P. Banyard
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Mon, 10 Apr 2023 at 20:12, Anton Smirnov wrote:
> Hello George,
>
> I'm not sure I'm 100% correct but I think that this RFC still allows to
> call different functions for the same code, just not in the same run.
>
> Consider this pseudocode:
>
> //- funcs.php
>
> namespace My;
>
> function myfunc(...) { ... }
> function array_map(...) { ... }
>
> //- code1.php
>
> namespace My;
>
> myfunc(1); // autoload triggered
> // bonus points if it's a different file or some obscure method
> array_map(strlen(...), []); // My\array_map
>
> //- code2.php
>
> namespace My;
>
> // no prior autoload
> array_map(strlen(...), []); // global array_map
>
No, array_map will trigger the autoloader (actually strlen() will trigger
it once first) and the autoloader should then load the array_map function
from the My namespace.
However, if the autoloader does not correctly load the My\array_map()
function then it will be bound to the global function.
I can add some test cases for that if needed.
> And if I understand the current order of execution correctly, here is a
> more extreme example:
>
> //- moreextreme.php
>
> namespace My;
>
> if (some_random()) {
> array_map('My\myfunc', []); // global array_map
> } else {
> array_map(myfunc(...), []); // My\array_map
> }
>
> --
> Anton
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 03:00, Sara Golemon wrote: > I'm sorry. I must be misunderstanding you. Are you implying PHP has no > native extension mechanism/API? > No. I can't see that reading in what I wrote. I'm saying that the DX for writing extensions is better in other languages. And that these days new products come along and provide extensions for other languages but not PHP. Which is a problem I can only work around by writing an extension. Or convincing them to write an extension. PHP now has FFI which provides an easier way to extend PHP. I have huge hopes for it - but in my experience it doesn't feel finished. php-vips is the biggest example of using it that I've seen. Peter
Re: [PHP-DEV] Future stability of PHP?
Just to follow up on that, and going totally off topic, I was reading about thanks.dev the other day. One of our concerns is that we can easily give money to top level projects or things we consciously add but how do you give it to all the dependencies and the thanks.dev approach seems a good idea (I have a separate problem in that our projects are rarely on GitHub or GitLab) but does anybody who would actually benefit from it have any thoughts on whether it would be good for them or not? > On 11 Apr 2023, at 10:09, Matthew Sewell wrote: > > What's meaningful in this sense? > > I have a budget for supporting open source projects (back to my money v time > point) and a percentage of that is for the PHP Foundation. I'd happily pay > LTS fees we pay elsewhere (even sometimes as a safety net) to the Foundation > but believe that the money we give to projects is just that, a donation that > the project can use as it sees fit, rather than the purchasing of a service > as we do commercially. > > Best wishes, > > Matt > >> On 11 Apr 2023, at 09:56, Marco Pivetta wrote: >> >> I'm also curious to hear whether any participants in this thread do/did >> support the PHP foundation in any tangible way :D >> >> If you treat it like an LTS provider, perhaps it's time to pay up the LTS >> support fees? >> >> Marco Pivetta >> >> https://mastodon.social/@ocramius >> >> https://ocramius.github.io/ >> >> >> On Tue, 11 Apr 2023 at 10:40, Alex Wells wrote: >> >>> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: >>> I don't want to use those weird stuff, but I'm doing the best I can to replace every single line of old code that has >>> been written in an era that "best practices for PHP development" were not what you and I know today. >>> >>> I still do not understand why you're expecting the whole PHP project to put >>> in enormous efforts to keep the backwards compatibility and solve your >>> problems (temporarily) instead of you doing so. What's stopping you from >>> using the last supported PHP version by that codebase and fixing or, worst >>> case scenario, rewriting it if you wish, while on that (non latest) PHP >>> version? What causes the desperation to update to the latest PHP? Is it new >>> features or security fixes, or both? >>> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
What's meaningful in this sense? I have a budget for supporting open source projects (back to my money v time point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS fees we pay elsewhere (even sometimes as a safety net) to the Foundation but believe that the money we give to projects is just that, a donation that the project can use as it sees fit, rather than the purchasing of a service as we do commercially. Best wishes, Matt > On 11 Apr 2023, at 09:56, Marco Pivetta wrote: > > I'm also curious to hear whether any participants in this thread do/did > support the PHP foundation in any tangible way :D > > If you treat it like an LTS provider, perhaps it's time to pay up the LTS > support fees? > > Marco Pivetta > > https://mastodon.social/@ocramius > > https://ocramius.github.io/ > > > On Tue, 11 Apr 2023 at 10:40, Alex Wells wrote: > >> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: >> >>> I don't want to use those weird stuff, but I'm >>> doing the best I can to replace every single line of old code that has >> been >>> written in an era that "best practices for PHP development" were not what >>> you and I know today. >>> >> >> I still do not understand why you're expecting the whole PHP project to put >> in enormous efforts to keep the backwards compatibility and solve your >> problems (temporarily) instead of you doing so. What's stopping you from >> using the last supported PHP version by that codebase and fixing or, worst >> case scenario, rewriting it if you wish, while on that (non latest) PHP >> version? What causes the desperation to update to the latest PHP? Is it new >> features or security fixes, or both? >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
I'm also curious to hear whether any participants in this thread do/did support the PHP foundation in any tangible way :D If you treat it like an LTS provider, perhaps it's time to pay up the LTS support fees? Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/ On Tue, 11 Apr 2023 at 10:40, Alex Wells wrote: > On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > > > I don't want to use those weird stuff, but I'm > > doing the best I can to replace every single line of old code that has > been > > written in an era that "best practices for PHP development" were not what > > you and I know today. > > > > I still do not understand why you're expecting the whole PHP project to put > in enormous efforts to keep the backwards compatibility and solve your > problems (temporarily) instead of you doing so. What's stopping you from > using the last supported PHP version by that codebase and fixing or, worst > case scenario, rewriting it if you wish, while on that (non latest) PHP > version? What causes the desperation to update to the latest PHP? Is it new > features or security fixes, or both? >
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 10 April 2023 13:17:04 BST, "G. P. B." wrote:
>Hello Internals,
>
>Dan and I would like to propose a new core autoloading mechanism that fixes
>some minor design issues with the current class autoloading mechanism and
>introduce a brand-new function autoloading mechanism:
>https://wiki.php.net/rfc/core-autoloading
Hi!
Thanks both for tackling this, I know function autoloading has long been on a
lot of people's wish lists.
A few thoughts:
> As a result of the pinning, function_exists() will return true for functions
> in namespaces that have been pinned to a global function.
The lookup pinning seems like the right way to optimise the implementation, but
I don't think it should be visible to user code like this - a lookup for
"strlen" in namespace "Foo" is not the same as defining the function
"Foo\strlen". Consider this code:
namespace Bar {
if ( function_exists('Foo\strlen') ) {
\Foo\strlen('hello');
}
}
namespace Foo {
strlen('hello'); // triggers name pinning
}
namespace Bar {
if ( function_exists('Foo\strlen') ) {
\Foo\strlen('hello');
}
}
If I'm reading the RFC correctly, the second function_exists will return true.
I'm less clear if the call to \Foo\strlen will actually succeed - if it gives
"undefined function", then function_exists is clearly broken; if it calls the
global strlen(), that's a very surprising side effect. For bonus points, the
call to strlen that triggers pinning could be inside an autoloader, making even
the first function_exists call return true.
Similarly, I think it should be possible to "unpin" a function lookup with a
later definition, even if no autoloading would be triggered. That is, this
should not be a duplicate definition error:
namespace Foo;
if ( strlen('magic') != 42 ) {
function strlen($string) { /* ... */ }
}
> The use of the word class in the API is currently accurate
This isn't actually true: classes, interfaces, traits, and enums all share a
symbol table, and thus an autoloader. I don't know of a good name for this
symbol table, though.
Regarding the API, would it be possible to take advantage of nearly all
autoloaders only being interested in particular namespace prefixes?
Currently, every registered autoloader is run for every lookup, and most
immediately check the input for one or two prefixes, and return early if not
matched. I suspect this design is largely because autoloading came before
namespaces, so the definition of "prefix" wasn't well-defined, but going in and
out of userland callbacks like this is presumably rather inefficient.
Perhaps the "register" functions should take an optional list of namespace
prefixes, so that the core implementation can do the string comparison, and
only despatch to the userland code if the requested class/function name matches.
Thanks again for working on this!
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > I don't want to use those weird stuff, but I'm > doing the best I can to replace every single line of old code that has been > written in an era that "best practices for PHP development" were not what > you and I know today. > I still do not understand why you're expecting the whole PHP project to put in enormous efforts to keep the backwards compatibility and solve your problems (temporarily) instead of you doing so. What's stopping you from using the last supported PHP version by that codebase and fixing or, worst case scenario, rewriting it if you wish, while on that (non latest) PHP version? What causes the desperation to update to the latest PHP? Is it new features or security fixes, or both?
Re: [PHP-DEV] PHP Modules
On Tue, 11 Apr 2023 at 04:41, Michael Morris wrote: > This will be long. I've read over the Future Stability thread and taken it > in, and decided to mull over an idea I touched on over a decade ago that I > think might help. Also, in the interceding years the JavaScript community > has overcome a compatibility issue using this technique, so we might do the > same. > > The crux of the stability problem is the need to update functions without > introducing a BC break. Adding in new features without removing old ones > also makes it confusing to incoming programmers as to what to use. > > I propose PHP Modules to hold new features. The existing namespace and > functions would be left alone. Existing files would also not be affected - > the behavior of PHP modules would be entirely opt in. > > They would work similar JavaScript modules - they would use the import > keyword and the include, require, include_once and require_once directives > would pitch an error if used in a PHP module. PHP Modules also would not > parse as templates at all - no opening that will be a headache for IDE makers, but it's not insurmountable). > > PHP would have a new ini directive to use them similar to the "type": > "module" directive that npm uses now. If that ini directive isn't set, php > files would be handled as they always have. mphp files would always be > handled as php modules though and lphp (legacy php) would always be handled > as legacy php. > > I expect some objection to file extensions affecting parsing behavior, but > over the last 5 years this approach has worked for the JavaScript community > with cjs, mjs and js files. Here the existing php, phtml, php3, php4 > extensions are handled as the directive instructs them to be handled, only > the two new never before used extensions of lphp and mphp would do their > thing. > > In a PHP module a function has to be imported before it's used with a > handful of exceptions. The root namespace of php modules is utterly empty, > or as close to empty as makes sense. > > The existing functions would be gathered into modules so that they can be > imported. While this is done the headache inducing inconsistencies like > haystack, needle for strings and needle, haystack for arrays can be > addressed. I really don't care which is adopted, but having one order for > this language wide would be nice. Also, decide once and for all - camelCase > or underscore_case. > > The above alone would be massive. Maybe it's impossible given the number > of devs available. The one thing modules can do that the current system > cannot is allow devs to pick which version of the module to use: > > import split from 'php.mb' // imports the mbsplit() function from the > current version of PHP. > > Say the mb module gets some bc breaks. We can put them into a new module so > that the behavior is once again opt in. The strongest way to do this is to > make composer a 1st class part of the language and let it specify the > version of the module that is loaded. > > The import command would be able to pull from the file system or from the > import map as JavaScript does currently. For ease of dev headaches I'd > recommend hewing to the JS model as close as possible as it is proven, and > many of us already use it anyway when developing browser code. > > I hope this helps, or at least spurs a conversation to come up with > something to address this issue. > One thing I like about PHP is that it has one mainline engine implementation with a single somewhat unfragmented ecosystem and it's an autoloading killer feature with Composer backing it up. I consider that combo to be the unique trait of PHP as the language and ecosystem. You change that, you basically convert PHP into JavaScript, Go, Ruby or any other modern language that's used widely in webdev. It loses its unique traits and is why many people like it - the ecosystem. I dabbled with NPM ecosystem enough to know that I'm gonna be the NYMBY type person screaming "GET OF MY LAWN!". Just look at Python and its 2 => 3 transition saga. PHP, the project, just does not have the resources to deal with something like this and maintain multiple major versions of the language. Don't forget - JavaScript's development is backed by some of the biggest corporations on the planet with functionally limitless budgets. They can afford have 1000 people working on the JS spec, engines, browsers and nodejs to sustain it all. Not even talking the amount of resources Google sunk into V8 to the point even Microsoft just gave up on Internet Explorer and migrated now runs Edge instead. Frankly, I think a lot of people have wholly unrealistic expectations of the scale and resources available to the PHP project - it's about 8 figure sum away on a yearly basis to be able to afford all the things people want PHP to do. And it will take at least half a decade just to onboard and get people familiar with the engine enough to even start major projects. And then there are
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
Hi George and Dan, pon., 10 kwi 2023 o 14:17 G. P. B. napisał(a): > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading > > The existing SPL autoloading functions would become aliases to the new Core > ones and will continue to work without any migrations needing to be > performed. > > Hope to hear your opinions about this! > > Best regards, > > George P. Banyard > Thanks for bringing this up, I like the RFC and addressing function autoload. Can we improve the RFC with a short description of issues on SPL autoload this RFC tries to address? It is mentioned in at least two places that this proposal addresses some minor issues with SPL autoload. However, I think it'd be worth mentioning them in RFC so the reader can get a complete picture of what the RFC tries to address besides adding new features like function autoload. Cheers, Michał Marcin Brzuchalski
