[Rd] [RFC] readtable enhancement
g@bembecker @end|ng |rom gm@||@com
Thu Mar 28 06:55:06 CET 2019
Cool idea and great "seeing new faces" on here proposing things on here and
engaging with R-core on here.
Some comments on the issue of fallbacks below.
On Wed, Mar 27, 2019 at 10:33 PM Kurt Van Dijck <
dev.kurt using vandijck-laurijssen.be> wrote:
> In the meantime, I submitted a bug. Thanks for the assistence on that.
> > and I'm not convinced that
> > coercion failures should fallback gracefully to the default.
> the gracefull fallback:
> - makes the code more complex
> + keeps colConvert implementations limited
> + requires the user to only implement what changed from the default
> + seemed to me to smallest overall effort
> In my opinion, gracefull fallback makes the thing better,
> but without it, the colConvert parameter remains usefull, it would still
> fill a gap.
Another way of viewing coercion failure, I think, is that either the
user-supplied converter has a bug in it or was mistakenly applied in a
situation where it shouldn't have been. If thats the case the fail early
and loud paradigm might ultimately be more helpful to users there.
Another thought in the same vein is that if fallback occurs, the returned
result will not be what the user asked for and is expecting. So either
their code which assumes (e.g., that a column has correctly parsed as a
date) is going to break in mysterious (to them) ways, or they have to put a
bunch of their own checking logic after the call to see if their converters
actually worked in order to protect themselves from that. Neither really
seems ideal to me; I think an error would be better, myself. I'm more of a
software developer than a script writer/analyst though, so its possible
others' opinions would differ (though I'd be a bit surprised by that in
this particular case given the danger).
> R-devel using r-project.org mailing list
[[alternative HTML version deleted]]
More information about the R-devel