As it so happens, the network and file ports seem to want to make COPY "get data out of the port's buffer".

The idea is that you ask for a READ, asynchronously. Then you wait for a wake up event. This event arrives with no information other than it was a "receive" event that happened on that the data does not live in the event (it can't, EVENT! is too small to hold both the port it is notifying and the pointer to data).

So in the code you write for processing the read event, it's time to get the data out of the port. This was done with COPY.

I think this is a bad way to think about the internal mechanics of asynchronous requests (and I have an unfinished post where I critique the whole thing).

Either way: from the perspective of a synchronous file user, this distinction doesn't exist. So copy %foo and read %foo are the same thing...get the data out of the file as a BINARY!.

Should PORT! Be Able To Overload COPY?

There are some things I feel like PORT! probably should not be overriding. TYPE OF, for instance.

>> type of %foo.jpg
== #[datatype file!]

I'm pretty sure this is an example of where we'd like to know that's a stringish proxy for a FILE! port, vs making a port and having it come back with something else:

>> type of %foo.jpg
== 'JPEG

Is COPY another one of these "reserved things" that you don't really get to redefine in any sense other than "make another instance of yourself"?

>> copy %hello.txt
== %hello.txt  ; as opposed to reading the contents of %hello.txt

One could certainly imagine the argument that not only does FILE! override COPY, but it adds an argument...the filename of the file to copy to:

>> copy %source.dat %destination.dat

In any case, COPY's days are numbered as the method for extracting things from internal buffers in ports. But that doesn't answer the question: Can ports override COPY, and if they do, are there rules about it?

1 Like