I think having a generic attach might be useful in the end. But I agree that some more thought needs to go into how such a generic would behave. I've always avoided using `attach()' precisely because I didn't fully understand the semantics.
One related possibility would be to create a method for `with()' (which is already generic) which would work on (in my case) "filehash" databases. It still wouldn't be quite as nice as `attach()' for interactive work but it could serve some purposes. -roger [EMAIL PROTECTED] wrote: > What have I started? I had nothing anywhere near as radical as that > in mind, Peter... > > One argument against making 'attach' generic might be that such a > move would slow it down a bit, but I can't really see why speed would > be much of an issue with 'attach'. > > I've noticed that David Brahm's package, g.data, for example really > has a method for attach as part of it, (well almost), but he has to > calls it g.data.attach. > > Another package that has an obvious application for a method for > attach is the filehash package of Roger Peng. > > And as it happens I have another, but for now I call it 'Attach', > which is pretty unsatisfying from an aesthetic point of view. > > I think I'll just sew the seed for now. The thing about generic > functions is that if they exist people sometimes find quite > innovative uses for them, and if they come at minimal cost, and break > no existing code, I suggest we thik about implementing them. > > (Notice I have had no need to use a 'compatibility with another > system' argument at any stage...) > > --- > > Another, even more minor issue I've wondered about is giving rm() the > return value the object, or list of objects, that are removed. Thus > > newName <- rm(object) > > would become essentially a renaming of an object in memory. > > For some reason I seem to recall that this was indeed a feature of a > very early version of the S language, but dropped out (I think) when > S3 was introduced. Have I got that completely wrong? (I seem to > recall a lot of code had to be scrapped at that stage, including > something rather reminiscent of the R with(), but I digress...) > > Bill. > > > -----Original Message----- From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Dalgaard Sent: Sunday, > 5 February 2006 8:35 PM To: Venables, Bill (CMIS, Cleveland) Cc: > [EMAIL PROTECTED] Subject: Re: [Rd] a generic 'attach'? > > > <[EMAIL PROTECTED]> writes: > > >> Is there any reason why 'attach' is not generic in R? >> >> I notice that it is in another system, for example, > > > I wonder which one? ;-) > > >> and I can see some applications if it were so in R. > > > I suppose there is no particular reason, except that it was probably > "good enough for now" at some point in time. > > Apropos attach(), and apologies in advance for the lengthy rant that > follows: > > There are a couple of other annoyances with the attach/detach > mechanism that could do with a review. In particular, detach() is not > behaving according to documentation (return value is really NULL). I > feel that sensible semantics for editing an attached database and > storing it back would be useful. The current semantics tend to get > people in trouble, and some of the stuff you need to explain really > feels quite odd: > > attach(airquality) airquality$Month <- factor(airquality$Month) # > oops, that's not going to work. You need: detach(airquality) > attach(airquality) > > (notice in particular that this tends to keep two copies of the data > in memory at a time). > > You can actually modify a database after attaching it (I'm > deliberately not saying "data frame", because it will not be one at > that stage), but it leads to contorsions like > > assign("Month", factor(Month), "airquality") > > or > > with(pos.to.env(2), Month <- factor(Month)) > > (or even with(pos.to.env(match("airquality",search())),....)) > > I've been thinking on and off about these matters. It is a bit tricky > because we'd rather not break codes (and books!) all over the place, > but suppose we > > (a) allowed with() to have its first argument interpreted like the > 3rd argument in assign() > > (b) made detach() do what it claims: return the (possibly modified) > database. This requires that more metadata are kept around than > currently. Also, the semantics of > > attach(airquality) assign("foo", function(bar)baz, "airquality") aq > <- detach(airquality) > > would need to be sorted out. Presumably "foo" needs to be dropped > with a warning. > > Potentially, one could then also devise mechanisms for load/store > directly to/from the search path. > > Alternative ideas include changing the search path itself to be an > actual list of objects (rather than a nesting of environments), but > that leads to the same sort of issues. > > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
