[Rd] Possible changes to connections
Prof Brian Ripley
ripley at stats.ox.ac.uk
Thu May 31 18:11:42 CEST 2007
On Thu, 31 May 2007, mel wrote:
> Prof Brian Ripley a écrit :
>
>> When I originally implemented connections in R 1.2.0, I followed the model
>> in the 'Green Book' closely. There were a number of features that forced
>> a particular implementation, and one was getConnection() that allows one
>> to recreate a connection object from a number.
>
> I'm currently using connections (socketConnection(), etc)
> and I first want to *thank you* for this nice work.
> (imho, it's so much simpler than the underlying C/C++ stuff.)
>
>> I am wondering if anyone makes use of this, and if so for what?
>
> I use getConnection().
> In the context in which I use it, the number of the connection is
> known a priori.
I don't see how you can know it 'a priori': it is an implementation detail
(and since R itself uses connections, those details could easily change).
> So getConnection() is an easy way to access to the connection
> for the functions which need to.
> I do not however pretend this is the best way to proceed.
>
>> It would seem closer to the R philosophy to have connection objects that
>> get garbage collected when no R object refers to them. This would allow
>> for example
>> ... readLines(con <- gzfile("foo.gz")); close(con)
>> which is a little awkward but more importantly seems little understood.
>
> There could be/was the same debate in C/C++.
> That's may be just a matter of education about not forgetting
> to close previously opened doors !
When I ran some tests I found 7 packages on CRAN that in their tests were
not closing connections. Four of those are maintained by R-core members.
Even though none were by me, I think this is too easy to forget to do!
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel
mailing list