[Rd] [RFC] readtable enhancement

[Kurt Van Dijck]

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