[R] Why does a custom function called is.numeric.factor break lattice?

[sbihorel]

Hi,

Thanks everyone for all your insights...

I feel that the discussion is getting way deeper and more technical and 
it needs to be from the point of view of what I was trying to achieve 
with my little "is.numeric.factor" function (ie, checking if an object 
is a factor and if all levels of this factor can be coerced to numeric 
values).

I guess that, as Duncan pointed point, using dots in function names 
becomes bad practice for function starring "is". I'll rename my 
function, that's it.


On 11/16/2015 11:43 AM, Martin Maechler wrote:
>>>>>> Bert Gunter <bgunter.4567 at gmail.com>
>>>>>>      on Mon, 16 Nov 2015 08:21:09 -0800 writes:
>      > Thanks Duncan. You are right; I missed this.
>
>      > Namespaces and full qualification seems the only reliable solution to
>      > the general issue though -- right?
>
> Not in this case;  full qualification is very very rarely needed
> in package code (even some "schools" do use and propagate it
> much more than I would recommend), and we are talking about the
> lattice code, i.e., package code, not user code, here.
>
> I.e., using  base::is.numeric()  would not help at all: It
> will still find the bogous  is.numeric.factor because that is
> taken before the internal default method.
>
> Also, I'm almost sure S4 dispatch would suffer from the same
> feature of S (and hence R) here:  You are allowed to define
> methods for your new classes and they are used "dynamically".
> (I also don't think that the problem is related to the fact that this
>   a.b.c() case is S3-ambigous:  a() method for "b.c" or a.b() method for "c".)
>
> Unfortunately, this can be misused to define methods for
> existing ("base") classes in case they are handled by the default method.
> OTOH, if base/stats/... already *had* a 'factor' method for
> is.numeric(), be it S3 or S4, no harm would have been done by
> the bad user defined is.numeric.factor definition, thanks to the
> namespace technology.
>
> To get full protection here, we would have to
> store "the dispatch table for all base classes" (a pretty vague notion)
> with the package at package build time or install time ("load time" is too late:
> the bad  is.numeric.factor() could already be present at package load time).
>
> I'm not sure this would be is easily feasible.... but it may be
> something to envisage for R 4.0.0 ..
>
> Martin
>
>      > Cheers,
>      > Bert
>
>      > Bert Gunter
>
>      > "Data is not information. Information is not knowledge. And knowledge
>      > is certainly not wisdom."
>      > -- Clifford Stoll
>
>
>      > On Mon, Nov 16, 2015 at 7:42 AM, Duncan Murdoch
>      > <murdoch.duncan at gmail.com> wrote:
>      >> On 16/11/2015 10:22 AM, Bert Gunter wrote:
>      >>>
>      >>> There is no multiple dispatch; just multiple misunderstanding.
>      >>>
>      >>> The generic function is "is.numeric" . Your method for factors is
>      >>> "is.numeric.factor".
>      >>>
>      >>> You need to re-study.
>      >>
>      >>
>      >>
>      >> I think the problem is with S3.  "is.numeric.factor" could be a
>      >> "numeric.factor" method for the "is" generic, or a "factor" method for the
>      >> "is.numeric" generic.  Using names with dots is a bad idea. This would be
>      >> all be simpler and less ambiguous if the class had been named
>      >> "numeric_factor" or "numericFactor" or anything without a dot.
>      >>
>      >> Duncan Murdoch

-- 
Sebastien Bihorel
Cognigen Corporation
(t) +1 716 633 3463 ext 323
Cognigen Corporation, a wholly owned subsidiary of Simulations Plus, Inc.