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] 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] 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] PHP Modules
> On Apr 10, 2023, at 20:40, Michael Morris wrote: > > This will be long. Yes, it's long, so I'm going to focus on a couple things and not quote too much. > I propose PHP Modules to hold new features. What you seem to have described is improved lexical scoping. Rather than a shared "global" scope for classes, functions, constants, and variables, you'd like to allow files, or perhaps even statement lists (open brace to closed brace) to work as either independent or compositional scopes. Basically, make scopes in a certain mode of PHP act more like Javascript. I'll be honest, if we could throw away PHP's old behavior and make this the only mode, I'd be pretty happy. We can't of course, at best we'd have to mix (and yes, I know that's part of your suggestion). This is a LOT of complexity. Not impossible, nothing is, but I'm fairly confident it would make maintaining the runtime harder, and would notably slow execution. Not saying "no", since I lack that power, but I do want to make it clear how HARD this feature would be to implement well. > 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). I would suggest, as a compromise, keep the initial open tag (or maybe an alternative one, like I hope this helps, or at least spurs a conversation to come up with > something to address this issue. Lastly, like the stability thread, this isn't a new suggestion, and I'd recommend googling back through the archives for prior discussions. Past failures don't mean it won't work today... Opinions change and so does the runtime, but it may be helpful to understand the complexities presented by this strategy, and what the objections to it will likely boil down to. See also "PHP Editions" which is a different, but closely related proposal put forth by Andi as recently as the 7.x era. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP modules (pecl) and PHP codes (pear)
On Thu, Oct 29, 2009 at 10:34 AM, Samuel ROZE samuel.r...@gmail.com wrote: Hi, I'll have to develop a function like parse_url, but parse_referrer which provides informations about the URL (the referrer): provider, keywords, type of search (search, cache, translation, ...), real page url... I don't really know how I'll do that: using a .ini file like get_browser ? I think it will be too complicated and difficult to build.. but maybe it is a good idea ? Or create it in C as an extension... I want to know if compiled extensions in C are really faster than an PHP function ? Thanks ! Samuel. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As fas as I know, yes obviously faster, but I think that in your case it doesn't worth the extra time to build this functionality in C, because it is mostly regex based string parser, so the overall overhead is minimal. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP modules (pecl) and PHP codes (pear)
On 29.10.2009, at 12:34, Samuel ROZE wrote: Hi, I'll have to develop a function like parse_url, but parse_referrer which provides informations about the URL (the referrer): provider, keywords, type of search (search, cache, translation, ...), real page url... I don't really know how I'll do that: using a .ini file like get_browser ? I think it will be too complicated and difficult to build.. but maybe it is a good idea ? Or create it in C as an extension... I want to know if compiled extensions in C are really faster than an PHP function ? Usually, it is a good idea to write it in PHP at first and then port to C, if performance is poor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP modules (pecl) and PHP codes (pear)
Le jeudi 29 octobre 2009 à 14:03 +0300, Alexey Zakhlestin a écrit : Usually, it is a good idea to write it in PHP at first and then port to C, if performance is poor But I lose some time ! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP modules (pecl) and PHP codes (pear)
2009/10/29 Samuel ROZE samuel.r...@gmail.com: Le jeudi 29 octobre 2009 à 14:03 +0300, Alexey Zakhlestin a écrit : Usually, it is a good idea to write it in PHP at first and then port to C, if performance is poor But I lose some time ! (Reposting with ML included.) Yes, but as far as a PHP extension may take hundreds time to develop than a PHP function. If the PHP version is fast enough, you will win a huge amount of time, if not, you will only lose less than 1% of the overall dev time. The computation is quite easy. What is your reqs/second target ? -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP modules (pecl) and PHP codes (pear)
Le jeudi 29 octobre 2009 à 17:35 +0100, Patrick ALLAERT a écrit : 2009/10/29 Samuel ROZE samuel.r...@gmail.com: Le jeudi 29 octobre 2009 à 14:03 +0300, Alexey Zakhlestin a écrit : Usually, it is a good idea to write it in PHP at first and then port to C, if performance is poor But I lose some time ! Yes, but as far as a PHP extension may take hundreds time to develop than a PHP function. If the PHP version is fast enough, you will win a huge amount of time, if not, you will only lose less than 1% of the overall dev time. The computation is quite easy. What is your reqs/second target ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP modules (pecl) and PHP codes (pear)
Le jeudi 29 octobre 2009 à 17:37 +0100, Patrick ALLAERT a écrit : Yes, but as far as a PHP extension may take hundreds time to develop than a PHP function. If the PHP version is fast enough, you will win a huge amount of time, if not, you will only lose less than 1% of the overall dev time. The computation is quite easy. You're right... What is your reqs/second target ? I want that my parse_referer function act in 1 ms maximum, that's the problem. ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
