Gabe described my main concern. Specifying a coercion function asserts that the data (1) were what was expected and (2) were converted into what was expected. Allowing a coercer to delegate to a "next method" is a good idea, but keep in mind that any function that did that would not confer the beneficial constraints mentioned above.
We can continue the discussion at: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17546 Michael On Thu, Mar 28, 2019 at 1:35 AM Kurt Van Dijck < dev.k...@vandijck-laurijssen.be> wrote: > On wo, 27 mrt 2019 22:55:06 -0700, Gabriel Becker wrote: > > Kurt, > > 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 > > <[1]dev.k...@vandijck-laurijssen.be> wrote: > > > > Hey, > > 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). > > I see. > So if we provide a default colConvert, named e.g. colConvertBuiltin, > which is used if colConvert is not given? > 1) This respects the 'fail early and loud'. > 2) The user would get what he asks for > 3) A colConvert implementation would be able to call colConvertBuiltin > manually if desired, so have colConvert limited to adding on top of the > default implementation. > > If this is acceptable, I'll prepare a new patch. > > Kind regards, > Kurt > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
