If I can merge this thread with the one I started yesterday...
"If the object does not have a class attribute, it has an implicit
class..."
which I take to mean that if an object does have a class attribute it
does not also have an implicit class.
I think this is reasonable behavior. Consider the "Date" class, which
stores values as "numeric":
class(Sys.Date())
[1] "Date"
inherits(Sys.Date(),"numeric")
[1] FALSE
class(unclass(Sys.Date()))
[1] "numeric"
Sys.Date()%%2
Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects
Letting the modulus operator (as one example) inherit the numeric class
here could create problems.
I disagree.
A date object should probably extend integers rather than numerics, in the
first place.
However, if it extends numeric, then it extends numeric, otherwise it's a
contradiction.
So, inherits(Sys.Date(),"numeric") should return true.
Modulo operators should be defined for both dates and numerics.
However, the application of modulo operators to dates, is perhaps unclear,
at least in the general case, anyway.
so instead of hitting utils:::head.function, it hits utils:::head.default
I also see this behavior at least as far aback as 3.5.1, so its not new
to 3.5.3.
These seem like significant design flaws.
Implicit classes or whatever you want to call them, are clearly part of the
class hierarchy.
They should be included in inherits(), is() and standard method dispatch,
regardless of whether they are part of the class vector or not.
Also, is this something that was introduced in R 3.5.1?
The only thing worse than a design flaw is a design flaw that isn't
backward compatible.