[R-pkg-devel] Problems with too much testing
Duncan Murdoch
murdoch@dunc@n @end|ng |rom gm@||@com
Fri Apr 16 15:08:28 CEST 2021
An offline message said
"Oh, you mean you're asking for an actual object-oriented language that
hides the internal representations of objects from users of a package.
Unfortunately for all of us, that isn't R....."
Actually, I don't think that's what I want. We already have lots of
languages like that (and it's not too hard to integrate C++ with R, for
example), but I'm not tempted to move code from R to C++ unnecessarily:
there's too much mental overhead (for me) in handling the extra formality.
What I think I'd like is something closer to the :: versus :::
difference in R. In practice, it's purely a convention that ::: isn't
used. The package writer declares (via the NAMESPACE) that certain
functions are fair game and will tend to be stable over time, but can't
block access to the internal functions that aren't: users are free to
take chances and use :::.
I'd like to be able to declare that the order of components in a list
doesn't matter. I think the NULL component versus missing component is
basically a bug in the language, but it's such an old one that I don't
think it could be changed: so I'd like to be able to declare that it's
not a distinction anyone should depend on.
Both of these things could easily be handled by the existing S3
machinery. Instead of declaring my object to have class "mesh3d", I
could declare it to have class c("mesh3d", "unorderedList",
"ignoreNULL"), and comparison methods like base::all.equal() or
waldo::compare() would ignore the unimportant differences.
The hardest thing here would be to agree on the class names and what
they imply.
Duncan Murdoch
More information about the R-package-devel
mailing list