From murdoch at stats.uwo.ca  Thu Sep  1 12:32:19 2005
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Thu, 01 Sep 2005 06:32:19 -0400
Subject: [Rd] RFC: rawConnection (was "loop connections")
In-Reply-To: <df62er$jab$1@sea.gmane.org>
References: <dedndn$daj$1@sea.gmane.org>	<17168.15848.291481.473231@stat.math.ethz.ch>	<df5b90$1ba$1@sea.gmane.org>
	<431667BC.7050906@stats.uwo.ca> <df62er$jab$1@sea.gmane.org>
Message-ID: <4316D8B3.3040504@stats.uwo.ca>

dhinds at sonic.net wrote:
> Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> 
> 
>>I would implement it differently from the way you did.  I'd call it
>>a rawConnection, taking a raw variable (or converting something else
>>using as.raw) as the input, and providing both text and binary
>>read/write modes (using the same conventions for text mode as a file
>>connection would).  It *should* support seek, at least in binary
>>mode.
> 
> 
> I was trying to reuse as much of the textConnection semantics and
> underlying code as possible...
> 
> Having a rawConnection() entry point is simple enough.  Seeking also
> seems straightforward.  I'm not so sure about using as.raw().  I
> wondered about that, but also thought that rather than coercing to
> raw, it might make more sense to cast atomic vector types to raw,
> byte-for-byte.

I'd prefer as.raw, so that we don't end up with two incompatible ways to 
convert other objects to raw objects.

> Can you given an example of where a text-mode raw connection would be
> a useful thing?

No, but someone else might.  Why unnecessarily let the source of the 
bytes determine the mode of the connection?  In the case of 
textConnection, there are natural line breaks, so a text mode connection 
makes sense.  A raw object can contain anything, so why wouldn't someone 
want to put text in it some day?

Duncan Murdoch



[Rd] RFC: rawConnection (was "loop connections")
Duncan Murdoch