[Rd] [RFC] readtable enhancement

[Michael Lawrence]

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 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
> 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 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
> 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]]