[Rd] [RFC] readtable enhancement
|@wrence@m|ch@e| @end|ng |rom gene@com
Thu Mar 28 15:23:46 CET 2019
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:
On Thu, Mar 28, 2019 at 1:35 AM Kurt Van Dijck <
dev.kurt using 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
> > 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:
> > 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
> > 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,
[[alternative HTML version deleted]]
More information about the R-devel