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
bene
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]d
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.k...@vandijck-laurijssen.be> wrote:
> Hey,
>
> In the meantime, I submitted a bug
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 on
Just to clarify/amplify: on the bug tracking system there's a
drop-down menu to specify severity, and "enhancement" is one of the
choices, so you don't have to worry that you're misrepresenting your
patch as fixing a bug.
The fact that an R-core member (Michael Lawrence) thinks this is
worth
This has some nice properties:
1) It self-documents the input expectations in a similar manner to
colClasses.
2) The implementation could eventually "push down" the coercion, e.g.,
calling it on each chunk of an iterative read operation.
The implementation needs work though, and I'm not convinced
Thank you for your answers.
I rather do not file a new bug, since what I coded isn't really a bug.
The problem I (my colleagues) have today is very stupid:
We read .csv files with a lot of columns, of which most contain
date-time stamps, coded in DD/MM/ HH:MM.
This is not exotic, but the base
