[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