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
<maech...@stat.math.ethz.ch> wrote:
>>>>>> Bert Gunter <bgunter.4...@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.dun...@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
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
