[Rd] RFC: "loop connections"

[David Hinds]

On Sat, Aug 27, 2005 at 09:23:37AM +0100, Prof Brian Ripley wrote:
>
> >"loop" is short for "loopback".  A loop or loopback device is one that
> >just returns the data sent to it.
> 
> That is definitely not what text connections do, and not what I read the 
> proposal as being given the analogies to text connections.

Hmmm.  The distinction you are making seems to be a narrow one.  Or
maybe my analogy is lacking.  To be honest, I could care less about
the name; I wanted something short and more general than "text" but
I've apparently failed.

> - Text connections are a convenience to make it easy to use an object
>   containing character strings in a computation that expects to read
>   from a connection.

You're right, this isn't exactly the sense I was thinking of.  But a
binary analog of text connections also seems useful here, doesn't it?
Why should we be able to use objects for computations that expect text
mode connections, but not binary mode connections?  The computation I
want to use is readBin, and it expects a connection, and I want to
feed it an object instead.

> That is exactly what read-write anonymous file() connections are
> designed for.  They too come from the Green Book.  (If efficiency
> were an issue, a short purpose-designed C routine would be the
> answer.  But file connections are already much 'smarter' than the
> proposed implementation of loop connections and do allow seeking.)

Anonymous file() connections seem to be hidden temporary files and I
was trying to avoid going through temporary files just to cast between
data types.  But then I admit to not testing the relative overhead of
the two mechanisms.  I'd rather not write dedicated C routines when
readBin and writeBin already do exactly what I need.

I'm afraid you've stumped me: I thought this seemed like a clean and
orthogonal extension of the existing facility requiring minimal new
code.  If the answer is that it isn't in the Green Book, well, then
shoot, I guess you've got me there!

-- David Hinds