From jmc at research.bell-labs.com  Mon Sep  8 10:31:20 2003
From: jmc at research.bell-labs.com (John Chambers)
Date: Mon Sep  8 15:31:41 2003
Subject: [Rd] namespaces and S4 methods/classes
References: <3F58B5D6.23D704B@research.bell-labs.com>
	<3F5A6FD8.8010007@stat.auckland.ac.nz>
Message-ID: <3F5C84A8.18C16AB7@research.bell-labs.com>

Ross Ihaka wrote:
> 
> John Chambers wrote:
> > The current version of the methods package now has a namespace. Packages
> > using S4 methods and classes can have NAMESPACE files.  New directives
> > can be included in NAMESPACE files to import and export classes and
> > methods.
> 
> Looking good!  A couple of (quite possibly silly) questions:
> 
> 1) I'm using a saved image for a package which creates new generics.
>     Am I right in guessing that I use export() to make these generics
>     available?

Yes.  The intent is that if you create f and methods for it, then EITHER
export(f) OR exportMethods(f) will export the generic and its methods. 
If f was a generic in another package, exportMethods(f) will just export
the methods defined in this package (that's the current model, but there
are some questions about what one really wants to do).

> 
> 2) In the saved image case, would it make sense to export the generic,
>     but not the methods - i.e., did the association of the methods with
>     the generic happen pre-save?

Currently, it's all or nothing:  Either you export the generic and its
methods or neither.

There are a couple of reasons.  First, the export/import information is
in the NAMESPACE file only, separate from the package source; so, the
mechanism is to evaluate all the package source and then export the
named objects.  Second, because only object names are used, there is
currently no mechanism to export a partial definition of the generic
(which is probably the way to think of the generic-only export:  Export
the generic as it's defined after the setGeneric() call but before some
setMethod() calls).

It's fairly likely the mechanism will be extended.  For one thing, it
seems necessary eventually to exclude methods that have private classes
in their signature.  Otherwise the exported generic has methods for
classes that are undefined.

For example, suppose "a" is an exported class and "b" a private class in
the same package and both have methods for "[":
  setClass("a", ....)
  setMethod("[", "a", .....)
  setClass("b", ....)
  setMethod("[", "b", .....)

To export the full definition of class "a" one needs exportMethods("[")
in the NAMESPACE file.  But at the moment, this exports the method for
"b" as well.

Fixing such problems may be related to allowing export() to be
associated with source code rather than with explicit objects, as
mentioned earlier.  In the above example, the first two lines would be
in an export() but the other two lines would not.  (There are some
implementation questions here, of course.)

John

> 
> --
> Ross Ihaka                         Email:  ihaka@stat.auckland.ac.nz
> Department of Statistics           Phone:  (64-9) 373-7599 x 85054
> University of Auckland             Fax:    (64-9) 373-7018
> Private Bag 92019, Auckland
> New Zealand

-- 
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc


[Rd] namespaces and S4 methods/classes
John Chambers