The Problem with Delete (on Ports)

The implementation of delete as it applies to ports (such as delete a file) has been changed.

To understand the change, examine the heart of the code of the delete mezzanine function in 2.0:

>> source delete
...
...
    foreach file blk [
        ret: find/match/any file second p
        if none? ret [ret: file]
        either tail? ret [
            remove dir
        ] [
            dir: next dir
        ]
    ]
...

Essentially, delete on a file reads an entire directory, scans the directory to match the file name while at the same time moving the index for the directory port, then removes that entry.

This original design came from a desire to keep ports as much like series as possible. However, it's not very efficient. Imagine if the directory contains 2000 files. Delete would request all 2000 file names before taking action. And, if the files were on your server (for example accessed through an FTP port), then a whole lot of network traffic would be involved to do what seems like a simple operation. That's certainly not the REBOL way.

As a result R3.0 abstracts delete. I has become a port action, and its implementation is dependent on the port scheme (protocol). So, if your protocol directly supports delete (e.g. as does FTP), then the action can be taken directly, saving a lot of overhead in the I/O.

So, what about compatibility? For programs that just use delete, there should be no problems. For programs that implement port actions related to delete, well, the port model is different and improved in so many other ways, you'll get a chance to improve (and hopefully simplify) your delete code as part of it.

2 Comments