Euphoria
Ticket #702:
pathname and dirname - redundant?
-
Reported by
euphoric
Aug 12, 2011
Looks like these two functions do the very same thing (mostly). pathname() even uses dirname() in its example code!
Their output is different:
dirname("0000975159.txt") =
pathname("0000975159.txt") = C:\iNet_Server\htdocs\files
dirname("datafiles\0000975159.txt") = datafiles
pathname("datafiles\0000975159.txt") = C:\iNet_Server\htdocs\files\datafiles
Can we get rid of one of them?
Details
1. Comment by DerekParnell
Aug 12, 2011
Firstly, the documentation for these two functions is wrong. Currently it gives misleading details about what these functions do so we need to correct that.
dirname() returns whatever path text has been supplied in the input parameter, with the option of returning a '.' if there was no path text supplied.
dirname("../xyz/abc.txt") --> "../xyz"
pathname returns the full path text for the file supplied in the input parameter. The function first converts whatever was supplied into a fully qualified path and then returns everything except the filename portion.
pathname("../xyz/abc.txt") --> "/user/myself/projects/demo/xyz"
2. Comment by euphoric
Aug 13, 2011
Derek, that's what I gathered from the results. I was wondering if we could get one of them to do the work of both.
3. Comment by DerekParnell
Aug 13, 2011
Yes we could, but why do you think it is worth the effort?
4. Comment by euphoric
Aug 13, 2011
It doesn't seem like it would be a lot of effort for the minor reduction of clutter/redundancy. But maybe I don't comprehend the effort that would be required. :)
5. Comment by SDPringle
Aug 15, 2011
How much effort? How about the need to convert lines of code in all of the projects that 4.0 is being used with? Including those that are not ours? We have released already. I don't think it is fair to change this just on a whim now.
The routine regex:matches could have been changed only slightly to do the work of regex:find_all also but I wouldn't suggest changing this now. When you change the foundation the whole structure falls.
6. Comment by mattlewis
Aug 15, 2011
I agree with Shawn. Unless there's a really compelling reason, we shouldn't be making significant API changes without a really good reason. I'd classify removing a function as significant.
7. Comment by jeremy
Aug 28, 2011
I have not thought out the implications of how these two would merge but don't forget we can deprecate. Deprecation should be the means of ALL API removals. Under no circumstance should a method simply be removed w/o being in the deprecated state for some time.
Just because code exists that uses it does not mean that a method should not be deprecated. All methods that are redundant should have one of them deprecated. Right now we don't have deprecation as a keyword but we have documentation and change logs.
GitHub