override? argument in create-directory etc.
Shiro Kawai
(22 Apr 2020 20:57 UTC)
|
||
Re: override? argument in create-directory etc. Lassi Kortela (22 Apr 2020 21:01 UTC)
|
||
Re: override? argument in create-directory etc.
Lassi Kortela
(22 Apr 2020 21:06 UTC)
|
||
Re: override? argument in create-directory etc.
Shiro Kawai
(22 Apr 2020 21:13 UTC)
|
||
Re: override? argument in create-directory etc.
Lassi Kortela
(22 Apr 2020 21:28 UTC)
|
||
Re: override? argument in create-directory etc.
Lassi Kortela
(22 Apr 2020 21:48 UTC)
|
||
Re: override? argument in create-directory etc.
John Cowan
(22 Apr 2020 23:05 UTC)
|
||
Re: override? argument in create-directory etc.
Lassi Kortela
(22 Apr 2020 23:13 UTC)
|
||
(missing)
|
||
(missing)
|
||
Re: override? argument in create-directory etc.
Lassi Kortela
(22 Apr 2020 23:36 UTC)
|
||
Re: override? argument in create-directory etc.
Shiro Kawai
(22 Apr 2020 23:59 UTC)
|
> Hi, I'm pretty late on the discussion, but I just started implementing > srfi-170 to Gauche > to see how it works. Nice! > One thing I couldn't find in the discussion archive is the rationale of > override? optional > argument in create-{directory|fifo|hard-link|symlink}. It's not in > underlying POSIX call. > Supposedly it's for convenience, but I don't think it can reliably be > used (suppose two > process trying to create objects with the same name simultaneously), and > I feel better to leave it to the upper layer to handle various > application-specific > requirements. (ensure-directory-exists "foo" [permission-bits]) would be very useful. This would be a subset of the behavior of create-directory's current override flag. I agree about the other cases. In particular, deleting an existing file system object of whatever type happens to be there) and replacing it with another object of a particular type sounds quite hazardous. When replacing an object with the _same_ type of object, it is more likely that the programmer knows what they are doing.