[Rd] Namespace problem

[Martin Maechler]

>>>>> "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> [...]

    GB> I've checked that section, but I am not adding methods to generics, 
    >> 
    >> sure? 
    >> 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
    GB> preferable.  

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 
   'foo.bar'
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
>> 	used.