Re: walk_dir issue

new topic     » topic index » view thread      » older message » newer message

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".  smile
>
>
> 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". smile
> 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?

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu