An example sent by Ross Ihaka points out a non-obvious step needed to
export the results of setAs().
The as() mechanism can't use ordinary method dispatch because the second
argument is the name of a class, not an object from the class. So it
uses a "helper" function, coerce(), and sets methods for that
function.
Therefore, if you want to export the results of setAs(), at the moment
you will need to include
exportMethods(coerce)
in the NAMESPACE file.
HOWEVER, this points out a general flaw in the current mechanism: The
user is responsible for understanding what objects need to be exported.
In general it would be more natural, I think, to block out sections of
source code and instruct the system "Export what gets created in THIS
code." For example, one might embed the expressions in a call to an
export() function:
export({
.... whatever is meant to be public ...
})
It appears at first glance that an export() function could operate
compatibly as an addition to the current mechanism.
John
--
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
