1. Re: walk_dir issue
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 25, 2004
- 525 views
- Last edited Nov 26, 2004
Me wrote: > Robert Craig wrote: > >> Juergen Luethje wrote: > > <snip> > >>> It depends on what you actually want walk_dir() to do. >>> >>> a) According to the current documentation, the first parameter should be >>> a path name. At least on DOS and Windows, something that contains a >>> wildcard is not a valid path name. >>> Yes, if the first parameter actually is supposed to be a path name, >>> then I would expect that the user-defined routine would not be called >>> at all because no such directory as "C:\\*.txt" exists, and that >>> walk_dir() spits out an error message. >>> >>> b) On the other hand, if it is intended that the first parameter of >>> walk_dir() may contain wildcards, then the documentation should be >>> changed accordingly. And the walk_dir() function must be changed, so >>> that -- regarding my previous example -- onyly "C:" is given to the >>> user-defined function as the path name, rather than "C:\\*.txt", >>> because "C:\\*.txt" is not a path name. >> >> I definitely intended and documented it as (a). >> >> The fact that walk_dir doesn't immediately crash and burn >> when given wildcards, is just a fluke, based on the >> fact that dir() accepts wildcards, which is also a fluke >> (now documented). I didn't even know myself that >> Euphoria's dir() worked with wildcards, until a user >> pointed it out to me. By the way, dir() does >> not work with wildcards on Linux/FreeBSD. >> >> To keep everyone happy, I'll add "the directory path must not >> contain wildcards" to the docs. Sort of like "This machine >> converts oranges into orange juice. Do not insert watermelons". > > > The main issue is not in the docs, but in the walk_dir() function itself. > Here is the beginning (2.5 alpha -- I left out some comments): > }}} <eucode> > global function walk_dir(sequence path_name, integer your_function, > integer scan_subdirs) > object d, abort_now > > -- get the full directory information > if my_dir = DEFAULT then > d = default_dir(path_name) > else > d = call_func(my_dir, {path_name}) > end if > if atom(d) then > return W_BAD_PATH > end if > </eucode> {{{ > > Why not add something like: > }}} <eucode> > if platform() != LINUX and > (find('*', path_name) or find('?', path_name)) then > return W_BAD_PATH > end if > </eucode> {{{ > > > Relying on the assumption that only proper arguments are passed to > functions is, say "very optimistic". > That's the reason why we also often use (built-in or user-defined) types > for parameter checking, no? ... so the following is probably better:
type path(object x) if atom(x) or find('*', path_name) or find('?', path_name) then return 0 end if return 1 end type global function walk_dir(path path_name, integer your_function, ^^^^ integer scan_subdirs) ...
Besides using the new type, there's no need to change the walk_dir() function, and there will be no speed loss at all, when "without type check" is used. Regards, Juergen -- Have you read a good program lately?