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. -- O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
