Ariel Scolnicov:
> It so happens that remove() is standard C (library) for removing a
> file. It therefore makes sense to use *that* name, if any change is
> made.
IMHO, it's poorly named (though using remove() at least has the virtue of
not conflicting with/overloading the existing "delete").
> Regarding the existence of multiple links -- That is probably an
> implementation detail of the platform on which the library is
> running. Since all remove() does is break the association between the
> name and the contents, links are a red herring.
No, remove() is a red herring, because it's only guaranteed to unlink() the
file, not actually remove it :). This is *why* I think it's poorly named
(on at least some platforms). If you're going to provide a way to remove()
(or delete(), or nuke(), or abolish(), or whatever word it goes by) a file,
the file should either go away or you should get an error. If all the call
does is break a link... you're unlink()'ing, not remove()'ing, and using
unlink() to be explicit about what's going on is a Good Thing.
If a remove() is added, it should (IMHO) seek-and-destroy. No, that's not
what the existing C function does... but if we're requiring people to be
aware of C functions, why not just stick with unlink()? (At least if there
aren't hordes of people out there who use perl who are aware of the standard
C libraries but who aren't familiar with standard Unix syscalls. I suspect
this is the case, but may be wrong.)
Overall, though, my main objections to changing unlink() are that (a) a
suitable replacement isn't obvious (to me, anyway ;) ) and (b) I don't see
any clear point at which to stop renaming things -- if we change unlink(),
shouldn't we also change chmod() and chown()? Should we change STDIN to
INPUT and STDOUT to OUTPUT and STDERR to ERROR ?
Although this is probably way more discussion than the subject warrants, so
I'll shut up now.
Dirk Myers
