[Rd] Namespace problem
maechler at stat.math.ethz.ch
Mon Sep 20 12:26:45 CEST 2004
>>>>> "GB" == Göran Broström <gb at stat.umu.se>
>>>>> on Mon, 20 Sep 2004 11:00:57 +0200 writes:
GB> On Mon, Sep 20, 2004 at 10:43:44AM +0200, Martin Maechler wrote:
>> >>>>> "GB" == Göran Broström <gb at stat.umu.se>
>> >>>>> on Sun, 19 Sep 2004 18:51:49 +0200 writes:
GB> I've checked that section, but I am not adding methods to generics,
>> Aren't you trying to export mlreg.fit
>> which looks like a 'fit' S3 method for the 'mlreg' generic?
GB> But it isn't. I just have found '.' to be a convenient separator in
GB> variable names, since '_' (my C favourite) wasn't available. So what you
GB> are suggesting
no!! I'm not.
GB> that I have to change all the variable names with dots in
GB> them. Or add 'S3metod(...' for each of them. I guess that the former is
no, really neither should be required.
We do encourage not using "." for new function names because of
the reason above, but it's definitely not a requirement.
In the case where 'foo' is an S3 generic function name,
we however recommend quite strongly not to use
as function name since it looks "too much" like an S3 method.
Is this the case for you?
GB> But how is this problem connected to using C/Fortran code?
only via "namespace magic".
E.g., for packages with namespaces and R 2.0.0,
it' will become recommended to *NOT* use the 'PACKAGE = "foobar"'
argument to .C(.) or .Fortran() calls because then, the package
version can be taken into account,
since NEWS for 2.0.0 has
>> C-LEVEL FACILITIES
>> o The PACKAGE argument for .C/.Call/.Fortran/.External can be
>> omitted if the call is within code within a package with a
>> namespace. This ensures that the native routine being called
>> is found in the DLL of the correct version of the package if
>> multiple versions of a package are loaded in the R session.
>> Using a namespace and omitting the PACKAGE argument is
>> currently the only way to ensure that the correct version is
More information about the R-devel