[Rd] a generic 'attach'?

[Prof Brian Ripley]

What are you proposing the generic be, and how should it be described?

Most of the currrent attach seems to be general, the only parts which are 
specific to save() images and lists are

         value <- .Internal(attach(NULL, pos, name))
         load(what, envir = as.environment(pos))
     }
     else value <- .Internal(attach(what, pos, name))

So maybe it is not attach() but some internal version of it (which 
populates a frame on the search list) which needs to be generic.  Indeed. 
dbLoad() in pkg filehash looks just what one wants here.

[That code is a bit strange: is not 'value' the environment into which you 
want to load things?  So why go via as.environment?]

The devil is in the `well almost'.

On Sun, 5 Feb 2006 Bill.Venables at 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'.

Speed is not an issue.  The major issue in making a function generic is 
describing what a generic function is required to do (including what it is 
required to return), and thereby ensuring that you do not break existing 
code without unduly limiting future uses.

> 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 candidate is lazyload/lazydata databases.

> 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...)

A good point, as it is not actually documented to be generic under that 
systems, as far as I can see.

[...]

-- 
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