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" <matth@apache.org>
>> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|