From blindglobe at gmail.com  Wed Feb  9 20:07:02 2005
From: blindglobe at gmail.com (A.J. Rossini)
Date: Wed Feb  9 20:07:12 2005
Subject: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)
In-Reply-To: <16906.14032.589706.230256@mithrandir.hornik.net>
References: <42088443.2090206@wiwi.uni-bielefeld.de>
	<16904.39235.910508.75875@stat.math.ethz.ch>
	<1abe3fa9050208043374d362df@mail.gmail.com>
	<16904.51238.148743.149665@stat.math.ethz.ch>
	<1abe3fa905020808481647d78d@mail.gmail.com>
	<16904.63694.9500.496681@mithrandir.hornik.net>
	<x21xbppw24.fsf@biostat.ku.dk>
	<16906.14032.589706.230256@mithrandir.hornik.net>
Message-ID: <1abe3fa905020911071a38acc9@mail.gmail.com>

On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
<Kurt.Hornik@wu-wien.ac.at> wrote:
> >>>>> Peter Dalgaard writes:
> 
> > Kurt Hornik <Kurt.Hornik@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@gmail.com


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