Unless we're actively trying to shrink the functionality of PHP's core,
I think we should.
There are things that were added to core rather than done in userland because:
distributing libraries in userland used to be a lot harder than it is now.
Some stuff needed to be in core to give adequate performance. As
userland PHP has had it's relative performance increased, and also
computers have gotten a little faster since the project began*, that
need has been greatly reduced.
One of the primary reasons for many of us — or at least me — to want more things in core is not listed above, and that reason is:
- Standardization
As a userland developer I would highly prefer to have the 20% of the functionality that most everyone needs 80% of the time be provided as standard functionality by the language rather than delegating the use-cases to userland resulting in a veritable Tower of Babble in the userland making too many projects incompatible with each other.
If we had more standardization we would have more shared knowledge across the PHP community. That makes it easier to hire developers, to be hired and to work on an open-source project as there would be less duplicated code that people would have learned that each is used very differently.
It would reduce the maintenance burden on userland developers where a few developers can implement the functionality that the major of developers no longer have to implement.
It would reduce dependencies required. Ironically I was just watching Github Satellite talk yesterday where they went on and on about how hard it is to manage and maintain dependencies.
And when we use PHP CLI we would generally be able to depend on any standardized functionality being there.
In many ways, I agree. In other ways, I see things like
array_column()andstr_contains()[1] as being obvious additions to the core, since they’re implemented in userland so often.
Exactly. The more functionality that is standardized and "just there" the better.
HOWEVER, I do recognize and appreciate at least one of Dan's concerns, if I interpreted correctly he wants to minimize the maintenance required for PHP core. Maybe it we all put our heads together we can get both?
1.) Minimize maintenance for PHP core, AND
2.) Standardize the most commonly-used requirements for functionality?
One potential option that comes to mind is a standard library of PHP-written functionality bundled in a PHAR file that would be included with future implementations of PHP and automatically included by PHP.
If we had such as standard PHAR then we could add "standardize" functionality for all PHP developers and yet reduce the pressure on core developers to implement and maintain said functionality in PHP C source code.
This would also open up the potential to contribute to PHP to all of userland, adding many more potential contributors and providing a relief valve for the C developers maintaining core so there would not be as much pressure to include things in core and they could easily say "Not in 'core; do the standard lib instead."
Thoughts?
-Mike
P.S. One argument against a standard library might be that developers would each want something different for the same use-case so we cannot standardized.
While it is true developers would each have different opinions on what we should add I think it is also true that — while developers will choose wildly different approaches in userland — once something is in a standard library most developers just accept it and move on. And those that don't will still be free to write their own as they have always been.
Hi!
One of the primary reasons for many of us — or at least me — to want
more things in core is not listed above, and that reason is:
- Standardization
Core and standardization are completely different things. There are a
lot of things in PHP that are being standardized out of core, and
putting something into core just for standardization is the wrong place
to do it.
To me, this feature clearly looks at something that belongs to
userspace, and magic that it introduces looks like it shouldn't be in
core but in some kind of module, or even better, IDE. Putting sematic
features like deprecation into runtime is not right, if deprecated code
got into runtime, putting out a warning each time it is run is useless.
If nobody looked at these warnings before they got to production, surely
nobody will look at them after.
--
Stas Malyshev
smalyshev@gmail.com
One of the primary reasons for many of us — or at least me — to want
more things in core is not listed above, and that reason is:
- Standardization
Core and standardization are completely different things.
I agree that they can be viewed as two different things.
There are a lot of things in PHP that are being standardized
out of core, and putting something into core just for
standardization is the wrong place to do it.
However, it is the defect-standardization of knowing a feature will be available that motivates my request.
While I certainly understand and respect your opinion, your opinion does not stop me (and likely others) from wanting defecto-standardization.
Yes people always want things, but this thing is actually a meta thing so it is different. This thing could address a wide swath of wants in the community and minimize the pressure for additions to the C++ based core.
To me, this feature clearly looks at something that belongs to
userspace,
That does not address the objective: defecto-standardization of always-available functionality.
and magic that it introduces
Requiring a use statement would be fine. It does not have to be "magic."
The key would be to have the functionality accessible via only PHP code.
but in some kind of module, or even better, IDE.
Having to use a specific IDE, to use Composer, or otherwise actively seek out and download this library also does not address the objective.
Please, if you will, take this as user feedback on PHP where a userland PHP developer is saying the DX (developer experience) would be a lot better if PHP had a standard library we could assume is always there.
Putting sematic
features like deprecation into runtime is not right, if deprecated code
got into runtime, putting out a warning each time it is run is useless.
If nobody looked at these warnings before they got to production, surely
nobody will look at them after.
That is unrelated. I was not addressing deprecation in this thread.
-Mike
P.S. I forgot to mention Larry Garfield's post on this subject. His post caused me to think of writing this thread, so here it is:
One potential option that comes to mind is a standard library of PHP-written functionality bundled in a PHAR file that would be included with future implementations of PHP and automatically included by PHP.
This was the gist of Larry’s comments on the other thread1. Pasted here, for reference:
Between preloading, PHP 7's improvements, FFI funkiness,
and the upcoming JIT, there's been on and off discussion
about moving much of the standard library from C to "PHP
code that is bundled and preloaded automatically." A real
"standard library" in PHP, rather than a bunch of bridged
C functions that exist for the legacy reasons Dan notes
above.Making that actually a thing would help obviate a lot of
these issues, I think. It becomes no longer an
implementation question but "just" a packaging question.
It wouldn’t need to be a PHAR file, but the general idea is the same: move a lot of the stuff that can be implemented (without losing performance) into pure PHP code, while keeping it part of php-src, and somehow package and bundle it with the php binary (or otherwise include it so that those symbols are loaded when PHP “starts up”).
IIRC, HHVM also does something like this (or did), and I would be in favor of this in PHP.
Cheers,
Ben
This idea has been brought up during the RFC for preloading. I think it's a good idea because it will make the c part smaller, and reduce the cost of maintenance. The question is, where should we start with? the existing functions in C work well, why should we put effect to convert them back to php. For new functions, it means more workload. The RFC's author has to convince others that this feature is better to implement in PHP rather than in C.
Regards,
CHU Zhaowei
-----Original Message-----
From: Mike Schinkel mike@newclarity.net
Sent: Friday, May 8, 2020 10:03 AM
To: Dan Ackroyd Danack@basereality.com
Cc: Rowan Tommins rowan.collins@gmail.com; PHP internals internals@lists.php.net; Ben Ramsey ben@benramsey.com
Subject: [PHP-DEV] A Standard PHAR library included with PHP?
Unless we're actively trying to shrink the functionality of PHP's
core,I think we should.
There are things that were added to core rather than done in userland because:
distributing libraries in userland used to be a lot harder than it is now.
Some stuff needed to be in core to give adequate performance. As
userland PHP has had it's relative performance increased, and also
computers have gotten a little faster since the project began*, that
need has been greatly reduced.
One of the primary reasons for many of us — or at least me — to want more things in core is not listed above, and that reason is:
- Standardization
As a userland developer I would highly prefer to have the 20% of the functionality that most everyone needs 80% of the time be provided as standard functionality by the language rather than delegating the use-cases to userland resulting in a veritable Tower of Babble in the userland making too many projects incompatible with each other.
If we had more standardization we would have more shared knowledge across the PHP community. That makes it easier to hire developers, to be hired and to work on an open-source project as there would be less duplicated code that people would have learned that each is used very differently.
It would reduce the maintenance burden on userland developers where a few developers can implement the functionality that the major of developers no longer have to implement.
It would reduce dependencies required. Ironically I was just watching Github Satellite talk yesterday where they went on and on about how hard it is to manage and maintain dependencies.
And when we use PHP CLI we would generally be able to depend on any standardized functionality being there.
In many ways, I agree. In other ways, I see things like
array_column()andstr_contains()[1] as being obvious additions to the core, since they’re implemented in userland so often.
Exactly. The more functionality that is standardized and "just there" the better.
HOWEVER, I do recognize and appreciate at least one of Dan's concerns, if I interpreted correctly he wants to minimize the maintenance required for PHP core. Maybe it we all put our heads together we can get both?
1.) Minimize maintenance for PHP core, AND
2.) Standardize the most commonly-used requirements for functionality?
One potential option that comes to mind is a standard library of PHP-written functionality bundled in a PHAR file that would be included with future implementations of PHP and automatically included by PHP.
If we had such as standard PHAR then we could add "standardize" functionality for all PHP developers and yet reduce the pressure on core developers to implement and maintain said functionality in PHP C source code.
This would also open up the potential to contribute to PHP to all of userland, adding many more potential contributors and providing a relief valve for the C developers maintaining core so there would not be as much pressure to include things in core and they could easily say "Not in 'core; do the standard lib instead."
Thoughts?
-Mike
P.S. One argument against a standard library might be that developers would each want something different for the same use-case so we cannot standardized.
While it is true developers would each have different opinions on what we should add I think it is also true that — while developers will choose wildly different approaches in userland — once something is in a standard library most developers just accept it and move on. And those that don't will still be free to write their own as they have always been.
This idea has been brought up during the RFC for preloading. I think it's a good idea because it will make the c part smaller, and reduce the cost of maintenance. The question is, where should we start with? the existing functions in C work well, why should we put effect to convert them back to php. For new functions, it means more workload. The RFC's author has to convince others that this feature is better to implement in PHP rather than in C.
I agree that the RFC for this must make a compelling case for it, since it will require work in the core to make this possible, and that work probably won’t be trivial.
As for porting code from C into PHP, I don’t think it has to be done en masse. I would start with no more than a handful of simple functions (maybe even uniqid(), since that’s where this discussion began) that would act as examples.
Once the capability for this is implemented and shipped, I think finding contributors to port functionality on a function-by-function basis won’t be difficult, since more folks in the community will be able to contribute, but it also doesn’t need to be done at a rapid pace, either. The primary benefit of porting from C to PHP in the core, IMO, is for greater opportunities for contributions and maintenance from the community.
Cheers,
Ben