And isn't it always simpler if the name of the method perfectly explains its functionality instead of relying on some convention?

(Ok, that is not always possible, but it IS in this case.)

Regards,
Paulo

Christoph Reck wrote:

Paulo Gaspar wrote:

To complitelly avoid ambiguities, why not calling it "getParentPath()" instead?


Keep it simple...

Any file-system object (file or directory) has a name and a path
to it. The simple rule is
  fileNameAndPath := FilenameUtils.getFullPath( fileNameAndPath )
                   + File.separatorChar
                   + FilenameUtils.getName( fileNameAndPath )

                  := FilenameUtils.concat(
                         FilenameUtils.getFullPath( fileNameAndPath ),
                         FilenameUtils.getName( fileNameAndPath ) )

Is this agreable by everyone? Why compicate the matters?

Notable is that a directory itself is positioned at a path location.
Therefore
FilenameUtils.getPath(pathToDirectory).length() < pathToDirectory.length()


Cheers,
Christoph


Regards, Paulo Gaspar

Stephen Colebourne wrote:

I think its best to change it. After all calling getPath() returns a path,
but calling getPath() on that result doesn't return the same path, but the
parent.


If I add a getParent() method, that can cover the existing case of this
method.

And these name manipulations have to be independent of File objects I
reckon.

Stephen

----- Original Message -----
From: "matthew.hawthorne" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, November 27, 2004 7:07 PM
Subject: Re: [io] Exact meaning of getPath, esp. on UNIX?




Stephen Colebourne wrote:


getPath is currently coded so that:
 "/a/b/c.txt"  --> "/a/b"
this is of course correct.

However, it is also coded to do:
"/a/b/c" --> "/a/b"
which seems a little odd (for me with a windows background). ie. the


method


treats 'c' as a file not a folder.


This method seems to behave the same as the 'dirname' command in Unix.
It returns the directory containing the item, whether the item is a file
or a folder.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to