[Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)

[A.J. Rossini]

On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
<Kurt.Hornik at wu-wien.ac.at> wrote:
> >>>>> Peter Dalgaard writes:
> 
> > Kurt Hornik <Kurt.Hornik at wu-wien.ac.at> writes:
> >> >>>>> A J Rossini writes:
> >>
> >> > But I don't see a problem with "package("package")", though I'm sure
> >> > I'm missing something.
> >>
> >> package() [sic] might be the creator for package objects, provided we
> >> can decide on what they are (and what kind of packages [source,
> >> installed, ...] they are used for).
> >>
> >> usePackage() or use_package() otoh would indicate to "use" a package
> >> (i.e., load and attach it).  The tricky part is deciding about the
> >> interface (e.g., finally disallowing non-standard evaluation as it is a
> >> programmer's nightmare) and what it should return.  And that is work in
> >> progress ...
> 
> > Any information on the rate...? (I still vote for usepackage() btw.)
> 
> Why not use(), as the GCD?

Excellent suggestion, Kurt.

> > It would be good if we could at least have an outline of the intended
> > functionality and see if we could forge ahead and get a preliminary
> > version done in time for 2.1.x
> 
> Help us out.
> 
>         use <- function(package, pos = 2, lib.loc, ...)

use <- function(packageName,pos=2,library, ...)

I could argue that "library" and "lib.loc" try to describe the same
thing (a name and its pointer).

> where 'package' is either a character string or some sort of package
> object/reference, to be specified later.  And 'lib.loc' needs to have a
> different name if we rename libraries into stores or whatever ...

I think package ought to be a character string.   Unless you want to
combine the packageName and libraryLocation into some form of data
object, or packageName, libraryLocation, and an environment containing
the erstwhile contents?

> What should this return?  Currently, 'library' returns the list of
> loaded (or available) packages by default, as a list of names, which is
> not good enough.  So we need something like the DLLInfoList returned by
> getLoadedDLLs() (and the docs should actually mention that class), or
> something usable by the package management tools ... and this is under
> redesign as well.

Perhaps "use" should incorporate "require" functionality, i.e. TRUE or
FALSE depending on whether you can use it after the "use" function
call.

> 
> But why should this really return info on all loaded/attached packages?
> An alternative might be just returning the package meta-data in some
> form.  Or nothing, which would fit into the idea that it really does
> nothing apart from loading and attaching a package.

I like "libraryContents()" or similar to figure out loaded and
potentially loadable packages.


> (And maybe a condition object inheriting from packageLoadAndAttachError
> in case of failure? :-))

Yes.  whatever.


-- 
best,
-tony

"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

A.J. Rossini
blindglobe at gmail.com