Hey,
I have created on GitHub a feature request for a path_join function (https://github.com/php/php-src/issues/11258) and got the label that this requires a RFC. So I am here now :)
The idea is to provide in PHP itself a function to join filesystem paths (idea: path_join) like in other languages, node as example (https://nodejs.org/api/path.html#pathjoinpaths). For me this function is some kind of base filesystem functionality like basename, realpath.
Example usage:
path_join('/base', 'my', 'path'); // /base/my/path
path_join('/base', 'my', 'path', 'test', '..'); // /base/my/path
Why not just string concatenation?
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I think this can improve the developer experience when working with filesystems a lot and people can delete their implementation.
I am really looking for your feedback, right now I have no “karma points” to create a RFC in the wiki :)
Thanks,
Soner
Hey,
I have created on GitHub a feature request for a path_join function (
https://github.com/php/php-src/issues/11258) and got the label that this
requires a RFC. So I am here now :)The idea is to provide in PHP itself a function to join filesystem paths
(idea: path_join) like in other languages, node as example (
https://nodejs.org/api/path.html#pathjoinpaths). For me this function is
some kind of base filesystem functionality like basename, realpath.Example usage:
path_join('/base', 'my', 'path'); // /base/my/path
path_join('/base', 'my', 'path', 'test', '..'); // /base/my/pathWhy not just string concatenation?
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I think this can improve the developer experience when working with
filesystems a lot and people can delete their implementation.I am really looking for your feedback, right now I have no “karma points”
to create a RFC in the wiki :)Thanks,
Soner
I would like to have such a feature in php so I can ditch my own
implementation.
In case it is of interest, the implementation we use on Wikipedia
as part of MediaWiki, is available on Packagist:
https://packagist.org/packages/wikimedia/relpath
https://www.mediawiki.org/wiki/RelPath
--
Timo Tijhof,
Wikimedia Foundation.
https://timotijhof.net/
Hey,
I have created on GitHub a feature request for a path_join function (
https://github.com/php/php-src/issues/11258) and got the label that this
requires a RFC. So I am here now :)The idea is to provide in PHP itself a function to join filesystem paths
(idea: path_join) like in other languages, node as example (
https://nodejs.org/api/path.html#pathjoinpaths). For me this function is
some kind of base filesystem functionality like basename, realpath.Example usage:
path_join('/base', 'my', 'path'); // /base/my/path
path_join('/base', 'my', 'path', 'test', '..'); // /base/my/pathWhy not just string concatenation?
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I think this can improve the developer experience when working with
filesystems a lot and people can delete their implementation.I am really looking for your feedback, right now I have no “karma points”
to create a RFC in the wiki :)Thanks,
Soner
In case it is of interest, the implementation we use on Wikipedia
as part of MediaWiki, is available on Packagist:https://packagist.org/packages/wikimedia/relpath
https://www.mediawiki.org/wiki/RelPath--
Timo Tijhof,
Wikimedia Foundation.
https://timotijhof.net/Hey,
I have created on GitHub a feature request for a path_join function (
https://github.com/php/php-src/issues/11258) and got the label that this
requires a RFC. So I am here now :)The idea is to provide in PHP itself a function to join filesystem paths
(idea: path_join) like in other languages, node as example (
https://nodejs.org/api/path.html#pathjoinpaths). For me this function is
some kind of base filesystem functionality like basename, realpath.Example usage:
path_join('/base', 'my', 'path'); // /base/my/path
path_join('/base', 'my', 'path', 'test', '..'); // /base/my/pathWhy not just string concatenation?
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I think this can improve the developer experience when working with
filesystems a lot and people can delete their implementation.I am really looking for your feedback, right now I have no “karma points”
to create a RFC in the wiki :)Thanks,
Soner
Definitely a useful feature, but not sure it needs to be a core function.
It's very easy to implement in userland. Userland implementation also
allows people to better customize it to their needs. Never going to be
using it on windows? Just use /. Only going to be using it on windows? Just
use . Need to support URLs as well as windows directories, create a method
that allows specifying the separator. Just for the simple case of windows
vs *nix directories, how is it determined which separator to use? If it's
the operating system that the code is running on, then what about if I need
to generate a *nix style path even though I'm running on Windows, or vice
versa? My feeling is that for the function to be easy to use, you have to
cut out too many scenarios which causes users to have to fallback to their
own implementations anyway. Finally, there aren't going to be any
meaningful performance gains which would possibly justify not implementing
it in userland.
--
Chase Peeler
chasepeeler@gmail.com
Definitely a useful feature, but not sure it needs to be a core function.
I feel the same. There are countless useful utility functions which could
exist in core, many of which are even widely used and commonly reinvented
as userland functions, Many would also seem at least prima facie to be
complementary to existing functions which are in core. But my understanding
of the usual convention is that "lots of people would have a use for it"
isn't enough where no significant further justification or benefit can be
provided for introducing a new core function.
On a wider philosophy on the future of the language, I'd be more inclined
to support changes like this which went the extra mile and introduced new,
complete object classes to group related core functionality and slowly
deprecate the enormous stock library of the global function namespace,
which feels random enough as it is.
-Dave
Hi
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
Why is it necessary to strip the ending slash?
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I don't use Windows, but to the best of my knowledge, using the '/' is
equivalent to the backslash. Is there a case where the difference matters?
I am really looking for your feedback, right now I have no “karma points” to create a RFC in the wiki :)
If you want to proceed with an actual RFC, the folks handing out the RFC
karma would need your Wiki name.
Best regards
Tim Düsterhus
Hi,
Thank you for the proposal - it echoes somewhere inside me.
Just a little side-view of the problem...
Personally, I will be a fan of Kotlin-style Path API
E.g., the path is an object so we can get path items, and get
sub-path/resolve child nodes.
It appeared to be quite useful in practice.
Examples:
- https://stonesoupprogramming.com/2017/11/27/kotlin-path-interface/
- https://www.baeldung.com/kotlin/kotlin-path-api
Hi
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
Why is it necessary to strip the ending slash?
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I don't use Windows, but to the best of my knowledge, using the '/' is
equivalent to the backslash. Is there a case where the difference matters?I am really looking for your feedback, right now I have no “karma points” to create a RFC in the wiki :)
If you want to proceed with an actual RFC, the folks handing out the RFC
karma would need your Wiki name.Best regards
Tim Düsterhus--
To unsubscribe, visit: https://www.php.net/unsub.php
hello!
Hi,
Thank you for the proposal - it echoes somewhere inside me.
Just a little side-view of the problem...
Personally, I will be a fan of Kotlin-style Path APIE.g., the path is an object so we can get path items, and get
sub-path/resolve child nodes.
It appeared to be quite useful in practice.Examples:
- https://stonesoupprogramming.com/2017/11/27/kotlin-path-interface/
- https://www.baeldung.com/kotlin/kotlin-path-api
Hi
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
Why is it necessary to strip the ending slash?
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I don't use Windows, but to the best of my knowledge, using the '/' is
equivalent to the backslash. Is there a case where the difference matters?I am really looking for your feedback, right now I have no “karma points” to create a RFC in the wiki :)
If you want to proceed with an actual RFC, the folks handing out the RFC
karma would need your Wiki name.Best regards
Tim Düsterhus--
To unsubscribe, visit: https://www.php.net/unsub.php
Maybe im missing something here but the already available
dirname()does this. right?
https://www.php.net/manual/en/function.dirname.php
Maybe im missing something here but the already available
dirname()
does this. right?
https://www.php.net/manual/en/function.dirname.php
dirname just traverses up the directory, it doesn't join paths.
For example, this example won't be possible with dirname:
path_join('/root', '/foo\bar/baz', '../test', 'file.json'); // =>
/foo/bar/test/file.json
No stripping would be needed at the end :)
Yes I would like to work on an proper RFC and make thoughts on the already given feedback here :)
My wiki name is: shyim
Thanks!
Hi
When you concat just the paths you have to think about:
- normalize string part to strip ending slash
Why is it necessary to strip the ending slash?
- for windows compatibility you have to use DIRECTORY_SEPERATOR
I don't use Windows, but to the best of my knowledge, using the '/' is equivalent to the backslash. Is there a case where the difference matters?
I am really looking for your feedback, right now I have no “karma points” to create a RFC in the wiki :)
If you want to proceed with an actual RFC, the folks handing out the RFC karma would need your Wiki name.
Best regards
Tim Düsterhus
Hi
Please do not "top-post". Instead reply inline and cut the quoted parts
to a minimum.
No stripping would be needed at the end :)
I don't follow then.
Yes I would like to work on an proper RFC and make thoughts on the already given feedback here :)
Okay, let me add some additional questions for you to already think about:
- Should the function perform file system operations? Why? Why not?
- What is with stuff like Windows network shares that, to my
understanding, have multiple directory separators next to each other? - Is the name of the function the best? I'd probably drop the
underscore, because we already have 'pathinfo'.
I'd also like to use this opportunity to add a "+1" with regard to "make
this a proper class for manipulating paths, similarly to Python's
pathlib or so". I would find that much more useful than the proposed
function.
Best regards
Tim Düsterhus
Hi Soner
Yes I would like to work on an proper RFC and make thoughts on the already given feedback here :)
My wiki name is: shyim
Please apologize this large delay in handling your request. The number
of folks with the necessary permissions is small (but increasing them is
work-in-progress) and thus it was not handled in time. I've messaged the
relevant folks out-of-band and was told that you should now be able to
create an RFC. Please let me know if it doesn't work.
Best regards
Tim Düsterhus