-----Original Message-----
From: Martin Morgan [mailto:mtmorgan at fhcrc.org]
Sent: Tuesday, 30 June 2009 5:12 AM
To: Stavros Macrakis
Cc: Troy Robertson; r-devel at R-project.org
Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
Stavros Macrakis wrote:
On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan <mtmorgan at fhcrc.org
<mailto:mtmorgan at fhcrc.org>> wrote:
...I'm not sure that including a connection in a slot is going to be
a good
idea, though -- a connection has reference-like semantics, so you
end up with multiple objects pointing to the same connection, Also
an object is garbage collected the connection will not be closed
automatically.
I'm not sure I understand your point here. Having multiple objects
refer to the same connection seems like a perfectly reasonable and
useful thing, and garbage collection should work just fine -- when *all*
of the objects referring to that connection are unreachable, then the
connection is unreachable and will itself be garbage collected. No?
I meant that, in practice, there were enough additional pitfalls that I
wouldn't choose this route (placing a connection in an S4 slot) for
myself. These little experiments were enough to make me cautious...
setOldClass(c("file", "connection"))
## Attempt one -- prototype
setClass("Element",
representation=representation(conn="file"),
prototype=prototype(conn=file()))
## oops, all instances share a single connection
close(new("Element")@conn)
## oops, all new instances now have a closed (invalid) connection
## Attempt two -- initialize
setClass("Element",
representation=representation(conn="file"))
setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
callNextMethod(.Object, ..., conn=conn)
})
new("Element")
## oops, connection created but not closed; gc() closes (eventually)
## but with an ugly warning
## > gc()
## used (Mb) gc trigger (Mb) max used (Mb)
## Ncells 717240 38.4 1166886 62.4 1073225 57.4
## Vcells 37333395 284.9 63274729 482.8 60051033 458.2
## > gc()
## used (Mb) gc trigger (Mb) max used (Mb)
## Ncells 715906 38.3 1166886 62.4 1073225 57.4
## Vcells 37335626 284.9 63274729 482.8 60051033 458.2
## Warning messages:
## 1: closing unused connection 3 ()
setClass("ElementX", contains="Element")
## oops, two connections opened (!)
## > showConnections()
## description class mode text isopen can read can write
## 3 "" "file" "w+" "text" "opened" "yes" "yes"
## 4 "" "file" "w+" "text" "opened" "yes" "yes"
And while completely expected the action-at-a-distance of references has
the usual risks
x <- y <- new("Element")
close(x at conn)
y
An object of class "Element"
Slot "conn":
Error in summary.connection(x) : invalid connection
One place I know where S4 and connections are used effectively is in the
AnnotationDbi package in Bioconductor (I did not participate in
developing this package, so am probably misrepresenting its
implementation). Here there is a database connection. But it is stored
in an environment in an S4 class. This part of the class is used
essentially as a singleton -- AnnotationDbi creates packages containing
instances, and users load the package and hence single instance; the
interface never exposes the connection itself to copying. The database
functionality exposed to the user is read-only, and querying the
connection does not change it's state (other than opening it if it were
closed). I think the underlying connection has C code to tidy itself up
appropriately (and quietly) when eventually garbage collected. So yes,
connections and multiple references to them can be useful.
Martin