[PD-dev] Re: [PD] [folder_list]

[Hans-Christoph Steiner]

On Apr 1, 2006, at 9:09 AM, B. Bogart wrote:
>
> james tittle wrote:
>> On Mar 31, 2006, at 5:45 PM, Hans-Christoph Steiner wrote:
>>
>>> On Mar 31, 2006, at 11:42 AM, Frank Barknecht wrote:
>>>
>>>> Maybe [folder_glob] would be a better name? [folder_list] may lead
>>>> users to expect a list - of whatever kind - as a result. (I  
>>>> would  even
>>>> prefer [folder_ls] but that my be too unixish.)
>>>
>>>
>>>
>>> Yeah, [folder_list] is not the best name.  ls and glob are too
>>> UNIXish, tho I love UNIX. Hmm..  [file/listing]?  "list" really   
>>> seems
>>> to be the common word here.  [file_list] might be the best  bet.
>>> Folders are usually considered files, while files are not   
>>> considered
>>> folders ever..
>>
>>
>> ...random ideas, to get away from using "list":
>>
>> [folder_contents]
>> [directory_search]
>> [folder_directory]
>> [directory]
>> [folder_catalog]
>> [directory_index]
>> [folder_inventory]
>>
>> james

> folder_contents sounds damn clear!
>
> Is directory stuff and file stuff in the same lib or two different  
> ones?
>
> [directory/contents]
>
> [folder/contents]
>
> [file/folder_contents]
>

There would be one library, "file".  I think spliting them would make  
for a lot more work, and little gain.  Most file operations also  
apply to folders, like date, time, name matching, permissions, etc.

I like the idea of searching, since it does patterns, and is not  
limited to one folder (i.e. /home/*/.tcshrc).  Maybe:

[file/match]
[file/search]
[file/index]

And tho I am a UNIX geek, I think "folder" is the preferred term  
here.  Its more widespread and I think it makes more sense than  
"directory" when you look at it from the interface level, rather than  
the implementation.

.hc

________________________________________________________________________ 
____

                             http://at.or.at/hans/