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

[Bert Gunter]

Thanks, Martin.

You have clearly stated the issue that concerned me. I am sorry that
it cannot be (easily) resolved.


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 8:43 AM, Martin Maechler
<maechler at stat.math.ethz.ch> 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