Full agreement. Thanks, Kurt.
On Thu, 10 Feb 2005 08:53:03 +0100, Kurt Hornik
<[EMAIL PROTECTED]> wrote:
> >>>>> A J Rossini writes:
>
> > On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
> > <[EMAIL PROTECTED]> wrote:
> >> >>>>> Peter Dalgaard writes:
> >>
> >> > Kurt Hornik <[EMAIL PROTECTED]> 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.
>
> And so obvious :-)
>
> >> > 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).
>
> We need to decide whether to stay with the "library" concept, or maybe
> go for another one alongside.
>
> >> 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?
>
> For the time being, the package would definitely be specified as a
> character string with its name. But [RG will like this] I find it
> rather clumsy to have tons of equal-level arguments which in fact could
> use some hierarchical structure. What we really want is some
> SPECIFICATION of the package to be used, definitely including its name,
> but maybe also where it should come from (library location) or which
> version it should have at least or at most, etc. So something like
>
> use(package_spec("foo", version = ~ > "1.5.8"), pos = 12, ...)
>
> >> 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.
>
> As Brian said, we would most likely get rid of library() alongside.
>
> I would condiser the TRUE/FALSE paradigm outdated. The FALSE case
> really consists of a variety or error conditions, and we should return
> these as such (rather than indicating "oh there was some problem but
> were not telling you which one, unless you are a human reader and look
> at the condition message ...").
>
> >>
> >> 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.
>
> installed.packages() for the time being.
>
> >> (And maybe a condition object inheriting from packageLoadAndAttachError
> >> in case of failure? :-))
>
> > Yes. whatever.
>
> -k
>
--
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
[EMAIL PROTECTED]
______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
