Comments on: 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 Comments:
Brian Hawley
23-Mar-2007 14:40:18 |
This would be good for ports with command interaction semantics rather than series semantics, like database ports. A database port isn't a series but it could have a delete command. | Robert
24-Mar-2007 4:50:11 |
Compatibility? In such a cases don't care to much about it. Let's get this thing fixed once now, and we are a big step ahead. |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
