Re: [Rd] a generic 'attach'?

From: Roger Peng <rpeng_at_jhsph.edu>
Date: Sun 05 Feb 2006 - 14:17:27 GMT

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

Bill.Venables@csiro.au 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: pd@pubhealth.ku.dk
> [mailto:pd@pubhealth.ku.dk] On Behalf Of Peter Dalgaard Sent: Sunday,
> 5 February 2006 8:35 PM To: Venables, Bill (CMIS, Cleveland) Cc:
> r-devel@lists.r-project.org Subject: Re: [Rd] a generic 'attach'?
>
>
> <Bill.Venables@csiro.au> 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
Received on Mon Feb 06 01:23:58 2006

This archive was generated by hypermail 2.1.8 : Sun 05 Feb 2006 - 20:20:52 GMT