Type | Wish | Status | submitted | Date | 24-Apr-2014 02:46 |
---|---|---|---|---|---|
Version | r3 master | Category | Unspecified | Submitted by | fork |
Platform | All | Severity | minor | Priority | normal |
Summary | Audit and eliminate uses of PATH to mean "file path" |
---|---|
Description |
In the Rebol world, a PATH is a foundational type. So when something is shipped in the box with a name like SPLIT-PATH that contributes to confusion, compared to something like SPLIT-FILENAME. It might even be argued that the generality of PARSE is much greater. And it documents what's going on better if written out explicitly: PARSE file [ copy directory thru any "/" copy filename to end ] ...anyway, just a thought... in the "teach a man to fish" vs. "give him a fish" sense; and takes the pressure off explaining what split-filename does exactly, especially on the edge cases of no filename, no directory, filenames with multiple dots in them... In any case, this came up in #1204 with something like system/script/path referring to what should be either a FILE! or a URL! I suggest an audit so that nothing in the box uses the word "path" to describe a filesystem path. The case above could be system/script/location, although I don't fully understand if it's supposed to be able to work with literals like a string in which case maybe it should be system/script/source? |
Example code |
Assigned to | n/a | Fixed in | - | Last Update | 25-Apr-2014 20:12 |
---|
Comments | |
---|---|
(0004409)
rebolek 24-Apr-2014 08:22 |
Another Forkism.
SPLIT-FILENAME sounds like it should split filename to filename and suffix, not to split path to directory and filename. And then this: "I suggest an audit so that nothing in the box uses the word "path" to describe a filesystem path." - let's remove the fog: "nothing uses word "path" to describe a path." Does it make sense? |
(0004410)
fork 24-Apr-2014 08:54 |
Beyond the conflicts with path!, by your logic split-path interpreted as file path should not accept file leafs and instead break the path into a block of parts splitting out each directory as its own component.
You're ignoring the basic premise here that system/script/path coming back with a url is bad and attacking an off the cuff name alternative. I even suggested parse as being a clear and self documenting way of approaching the problem that could be easily adapted to practically any case with different requirements. I'm surprised you've not come across Rebol's path datatype. Google it. |
(0004411)
johnk 24-Apr-2014 12:24 |
As discussed on SO:
Gregg's split is a logical place for this function, and it close to working without modification. >> split %dir/other-dir/file.ext %/ == [%dir %other-dir %file.ext] Options include split/path or split/file as refinements to match the existing split-path behaviour. |
(0004412)
rgchris 25-Apr-2014 20:12 |
+1 @johnk, I'd suggest perhaps split/first and split/last may be a solution that could also be generally useful:
>> split/last %dir/other-dir/file.ext %/ == [%dir/other-dir %file.ext] Though still doesn't quite cover it as the first value doesn't retain the trailing / |
Date | User | Field | Action | Change |
---|---|---|---|---|
25-Apr-2014 20:12 | rgchris | Comment : 0004412 | Added | - |
24-Apr-2014 12:24 | johnk | Comment : 0004411 | Added | - |
24-Apr-2014 08:55 | fork | Comment : 0004410 | Modified | - |
24-Apr-2014 08:54 | fork | Comment : 0004410 | Added | - |
24-Apr-2014 08:22 | rebolek | Comment : 0004409 | Added | - |
24-Apr-2014 03:10 | fork | Description | Modified | - |
24-Apr-2014 03:09 | fork | Description | Modified | - |
24-Apr-2014 03:08 | fork | Type | Modified | Bug => Wish |
24-Apr-2014 02:47 | fork | Description | Modified | - |
24-Apr-2014 02:46 | fork | Ticket | Added | - |