Paulo Gaspar wrote:
And isn't it always simpler if the name of the method perfectly explains
its functionality instead of relying on some convention?
That was exactly the reason for my previous email.
The function getPath() is already straightforward. Any element
in a file system has a path - even directories. This is no
convention, but a fact (which sometimes it needs a second
thought to grasp).
By adding getParentPath would also require renaming the sister
function to getFullParentPath... :D and in the end, no one would
understand the reason for such function names.
So again, KISS!
Cheers,
Christoph
P.S. This is my last comment to this issue, so not to inch into a
flame thread :)
(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
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
