R help - Nov 2015 - Why does a custom function called is.numeric.factor break lattice?

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

Thanks Duncan. You are right; I missed this.

Namespaces and full qualification seems the only reliable solution to
the general issue though -- right?

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

>>>>> 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