Req #76702 [Opn]: pathinfo's $options should have a value for DIRNAME + FILENAME

From: Date: Sat, 04 Aug 2018 21:08:01 +0000
Subject: Req #76702 [Opn]: pathinfo's $options should have a value for DIRNAME + FILENAME
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-216585@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76702&edit=1 ID: 76702 Updated by: requinix@php.net Reported by: jerry at jmweb dot net Summary: pathinfo's $options should have a value for DIRNAME + FILENAME Status: Open Type: Feature/Change Request Package: Filesystem function related PHP Version: Irrelevant Block user comment: N Private report: N New Comment: The next step would be someone with C knowledge making a patch or pull request to add the functionality. It's not a particularly difficult change to implement: a new constant and the obvious edits to pathinfo() to support it. It's also subject to approval by the devs, of course, but I see no reason why something like this would be declined. As for when, I can't really say. Features tend to come in minor releases but 7.3 hit feature freeze earlier this week for a scheduled release this December; releases are yearly so 7.4 (or 8.0) would be out end of 2019. But I don't think there is a strict rule about minor improvements like this so it's up to the devs and RMs whether this goes with 7.3.0, or 7.3.x/7.2.y/7.1.z, or waits until 7.4. Assuming the change was written and submitted soon, of course. Previous Comments: ------------------------------------------------------------------------ [2018-08-04 20:42:31] jerry at jmweb dot net I vote for PATHINFO_DIRFILENAME. I see it more consistent to the existing PATHINFO_ family of constants. What is the next step? Unfortunately, I can't submit a patch since I do not know C. Also, what release would this feature target if approved? ------------------------------------------------------------------------ [2018-08-04 20:38:17] requinix@php.net Personally I would go for DIRFILE or DIRFILENAME - a combination of the DIRNAME and FILENAME constants (and one that fits the current naming style) which should help users remember it. ------------------------------------------------------------------------ [2018-08-04 19:21:57] jerry at jmweb dot net The output should follow the natural order of the file's path regardless of the order the bitmask was created. So (PATHINFO_DIRNAME | PATHINFO_EXTENSION) would be identical to the concatenation of pathinfo()'s matching indexes (['dirname'] . '/.' . ['extension']). The bitmask (PATHINFO_BASENAME | PATHINFO_FILENAME) would be normalized to just (PATHINFO_BASENAME) and return only the equivalent of pathinfo()'s (['basename']). I now see that accepting a bitmask value will make things convoluted since: PATHINFO_FILENAME | PATHINFO_EXTENSION -> same output as PATHINFO_BASENAME PATHINFO_FILENAME | PATHINFO_BASENAME -> normalized to PATHINFO_BASENAME PATHINFO_DIRNAME | PATHINFO_EXTENSION -> not useful Introducing a new constant for the DIRNAME + FILENAME combination sounds like a better solution. However, coming up an appropriate name escapes me at the moment. To kick-start the options, consider these: PATHINFO_FILEPATH PATHINFO_FILENAMEPATH PATHINFO_NO_EXTENSION PATHINFO_EXTENSIONLESS PATHINFO_DIRFILENAME ------------------------------------------------------------------------ [2018-08-04 13:47:32] a at b dot c dot de The same way BASENAME is FILENAME+EXTENSION? It would fill a hole in the matrix: dirname/filename.extension ------- -------- ********* EXTENSION ------- ******** --------- FILENAME ------- ******** ********* BASENAME ******* -------- --------- DIRNAME ******* ******** --------- ?[ROOTNAME? STEMNAME?] (the remaining three dirname/filename/extension combinations aren't useful). ------------------------------------------------------------------------ [2018-08-04 07:08:40] requinix@php.net So instead, how about a constant for the combined DIRNAME+FILENAME? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76702 -- Edit this bug report at https://bugs.php.net/bug.php?id=76702&edit=1

« previous php.bugs (#216585) next »