On Wed, Apr 28, 2021 at 6:04 PM brodie gaslam
wrote:
>
> > On Wednesday, April 28, 2021, 5:16:20 PM EDT, Gabriel Becker <
> gabembec...@gmail.com> wrote:
> >
>
> > The analogous case for non-closures to what you are describing would be
> for
> > S3 to check mode(x) after striking out with class(x
> On Wednesday, April 28, 2021, 5:16:20 PM EDT, Gabriel Becker
> wrote:
>
> Hi Antoine,
>
> I would say this is the correct behavior. S3 dispatch is solely (so far as
> I know?) concerned with the "actual classes" on the object. This is because
> S3 classes act as labels that inform dispatch wh
Hi Antoine,
I would say this is the correct behavior. S3 dispatch is solely (so far as
I know?) concerned with the "actual classes" on the object. This is because
S3 classes act as labels that inform dispatch what, and in what order,
methods should be applied. You took the function class (ie label
Dear R devel,
as.list() can be used on functions, but not if they have a S3 class that
doesn't include "function".
See below :
```r
add1 <- function(x) x+1
as.list(add1)
#> $x
#>
#>
#> [[2]]
#> x + 1
class(add1) <- c("function", "foo")
as.list(add1)
#> $x
#>
#>
#> [[2]]
#> x + 1
class(add1)
On Sat, Apr 17, 2021 at 7:07 PM SOEIRO Thomas wrote:
>
> Dear Deepayan,
>
> I do not have further suggestions, but I just wanted to thank you for taking
> the time to
> improve the documentation so much! (and for adding support for specifying
> "varying" as
> a vector)
>
> Both "Typical usage" a
On 4/28/21 6:20 PM, Toby Hocking wrote:
+1 for Martin's proposal, that makes sense to me too.
About Tomas' idea to immediately stop with an error when the user tries to
create a string which is invalid in its declared encoding, that sounds
great. I'm just wondering if that would break my applicat
+1 for Martin's proposal, that makes sense to me too.
About Tomas' idea to immediately stop with an error when the user tries to
create a string which is invalid in its declared encoding, that sounds
great. I'm just wondering if that would break my application. My package is
running an example duri
On 4/28/21 5:22 PM, Martin Maechler wrote:
Toby Hocking
on Wed, 28 Apr 2021 07:21:05 -0700 writes:
> Hi Tomas, thanks for the thoughtful reply. That makes sense about the
> problems with C locale on windows. Actually I did not choose to use C
> locale, but instead it was in
> Lluís Revilla
> on Wed, 28 Apr 2021 15:19:53 +0200 writes:
> Hi all,
> It has come to my attention that there is a new post on The R blog: "R
> Can Use Your Help: Testing R Before Release".
> However, the link returns an error "Not found":
>
https://developer.r
Hi Toby,
On 4/28/21 4:21 PM, Toby Hocking wrote:
> Hi Tomas, thanks for the thoughtful reply. That makes sense about the
> problems with C locale on windows. Actually I did not choose to use C
> locale, but instead it was invoked automatically during a package check.
I see, as long as the tests
> Toby Hocking
> on Wed, 28 Apr 2021 07:21:05 -0700 writes:
> Hi Tomas, thanks for the thoughtful reply. That makes sense about the
> problems with C locale on windows. Actually I did not choose to use C
> locale, but instead it was invoked automatically during a package c
Hi Tomas, thanks for the thoughtful reply. That makes sense about the
problems with C locale on windows. Actually I did not choose to use C
locale, but instead it was invoked automatically during a package check.
To be clear, I do NOT have a file with that name, but I do want file.exists
to return
Hi all,
It has come to my attention that there is a new post on The R blog: "R
Can Use Your Help: Testing R Before Release".
However, the link returns an error "Not found":
https://developer.r-project.org/Blog/public/2021/04/28/r-can-use-your-help-testing-r-before-release/index.html
Hope this mail
Hi Toby,
a defensive, portable approach would be to use only file names regarded
portable by POSIX, so characters including ASCII letters, digits,
underscore, dot, hyphen (but hyphen should not be the first character).
That would always work on all systems and this is what I would use.
Indiv
14 matches
Mail list logo