[Visualoberon-win32] Re: Initial cut of directory scanning module

[Michael G. <mgr...@co...>]

Michael van Acken wrote:

> nice to hear from you.  I'm not quite sure why you think I have "lots
> to say" on this matter, but hey, I'll whip up an opinion in no time ;-)
>
> 1) I would suggest to split enumerating the names in a directory and
>    getting data on the returned names.  The most important reason for
>    this is that enumerating the names is quite portable, while
>    obtaining file stats isn't.
>
>    Getting file info should be a different module, say "OS:Stat".
>    This module should provide a function to get a info object for a
>    file name, and this info object should have methods (_not_
>    attributes) to access all relevant information.  In particular, I
>    strongly suggest to drop the "is*" flags and replace each of them
>    with a predicate method for portability and efficieny reasons.
>    This methods would map to the C-level "S_IS*" macros.

Watch for the attribute interface coming soon.

>
>
> 2) The enumeration of the files should _not_ report the entries "."
>    and ".." to the caller.  Reason: They are always there, even if
>    some readdir()s don't report them, and most of the time the user
>    must filter them out anyway.

Ok, these entries have been filtered.

>
>
> 3) Don't ignore error messages with Open/Next/Close.

I'm going to ignore these errors since I don't know much
about how either the C interface or Oberon-2 errors work.
Anyone interested can add the error reporting.  For now,
a NIL return from Open means it didn't work and an empty
string from Next() means no more entries could be found.
I think that 99.9% of all directory lists will work with
this.  Remember the KISS principle.

>
>
> 4) The iterator pattern for this module should be as simple as
>    possible.  The simplest one I can come up with is

Mine is even simpler.  See attached TestDirectories.  I'm
using a returned string for the file entry so the interface to the
attributes module can be cleanly separated from this module.
Besides, you need a filename to get attributes anyway.  In
addition Directories can be used stand-alone if you don't
care about attributes and all you need is a list of filenames.

> 5) Document that the reported order of files is pretty much random.

Done.

>
>
> 6) I would consider skipping Rewind().  Would anybody miss the Unix
>    functions rewinddir(), telldir(), and seekdir()?  Probably not.

Done

>
>
> And when all is done, one could write yet another module that selects
> all files of a directory matching a regular expression and return them
> sorted according to a given relation.  The regexp matcher I justed
> checked in under libadt might come in handy there :-)

An exercise left to the reader.

>
>
> So, is this "lots" enough?
>

As usual you came through.  :-)

Michael G.