-
Notifications
You must be signed in to change notification settings - Fork 66
/
README.Rmd
90 lines (65 loc) · 3.7 KB
/
README.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
---
output: github_document
---
<!-- README.md is generated from README.Rmd. Please edit that file -->
```{r setup, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>",
fig.path = "man/figures/README-",
out.width = "100%"
)
```
# vctrs <a href="https://vctrs.r-lib.org"><img src="man/figures/logo.png" align="right" height="138" /></a>
<!-- badges: start -->
[](https://app.codecov.io/gh/r-lib/vctrs?branch=main)
[](https://github.com/r-lib/vctrs/actions/workflows/R-CMD-check.yaml)
<!-- badges: end -->
There are three main goals to the vctrs package, each described in a vignette:
* To propose `vec_size()` and `vec_ptype()` as alternatives to `length()` and
`class()`; `vignette("type-size")`. These definitions are paired with a
framework for size-recycling and type-coercion. `ptype` should evoke the
notion of a prototype, i.e. the original or typical form of something.
* To define size- and type-stability as desirable function properties, use
them to analyse existing base functions, and to propose better alternatives;
`vignette("stability")`. This work has been particularly motivated by
thinking about the ideal properties of `c()`, `ifelse()`, and `rbind()`.
* To provide a new `vctr` base class that makes it easy to create new S3
vectors; `vignette("s3-vector")`. vctrs provides methods for many base
generics in terms of a few new vctrs generics, making implementation
considerably simpler and more robust.
vctrs is a developer-focussed package. Understanding and extending vctrs requires some effort from developers, but should be invisible to most users. It's our hope that having an underlying theory will mean that users can build up an accurate mental model without explicitly learning the theory. vctrs will typically be used by other packages, making it easy for them to provide new classes of S3 vectors that are supported throughout the tidyverse (and beyond). For that reason, vctrs has few dependencies.
## Installation
Install vctrs from CRAN with:
```{r, eval = FALSE}
install.packages("vctrs")
```
Alternatively, if you need the development version, install it with:
```{r, eval = FALSE}
# install.packages("pak")
pak::pak("r-lib/vctrs")
```
## Usage
```{r}
library(vctrs)
# Sizes
str(vec_size_common(1, 1:10))
str(vec_recycle_common(1, 1:10))
# Prototypes
str(vec_ptype_common(FALSE, 1L, 2.5))
str(vec_cast_common(FALSE, 1L, 2.5))
```
## Motivation
The original motivation for vctrs comes from two separate but related problems. The first problem is that `base::c()` has rather undesirable behaviour when you mix different S3 vectors:
```{r}
# combining factors makes integers
c(factor("a"), factor("b"))
# combining dates and date-times gives incorrect values; also, order matters
dt <- as.Date("2020-01-01")
dttm <- as.POSIXct(dt)
c(dt, dttm)
c(dttm, dt)
```
This behaviour arises because `c()` has dual purposes: as well as its primary duty of combining vectors, it has a secondary duty of stripping attributes. For example, `?POSIXct` suggests that you should use `c()` if you want to reset the timezone.
The second problem is that `dplyr::bind_rows()` is not extensible by others. Currently, it handles arbitrary S3 classes using heuristics, but these often fail, and it feels like we really need to think through the problem in order to build a principled solution. This intersects with the need to cleanly support more types of data frame columns, including lists of data frames, data frames, and matrices.