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 < dev.kurt at 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). Best, ~G> ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
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.kurt at 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
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.kurt at 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.kurt at 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]]