Euphoria Ticket #702: pathname and dirname - redundant?

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?


Type: Task Severity: Normal Category: Language
Assigned To: unknown Status: New Reported Release:
Fixed in SVN #: View VCS: none Milestone:

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.


Quick Links

User menu

Not signed in.

Misc Menu