[Rd] ALTREP: Design concept of alternative string

[介非王]

Hello from Bioconductor,

I'm developing a package to share R objects across clusters using boost
library. The concept is similar to mmap package:
https://cran.r-project.org/web/packages/mmap/index.html . However, I have a
problem when I was trying to write Dataptr_method for the alternative
string.

Based on my understanding, the return value of the Dataptr_method function
should be a vector of CHARSXP pointers. This design might be problematic in
two ways:

1. The behavior of Dataptr_method function is inconsistent for string and
the other ALTREP types. For the other types we return a vector of pure data
in memory allocated outside of R, but for the string, we return a vector of
R objects allocated by R.

2. It causes an unnecessary duplication of the data. In order to return
CHARSXPs to R, It forces me to allocate CHARSXPs and copy the entire data
to the R process. By contrast, for the other ALTREP types, say altreal, I
can just return the pointer to R if the data is in the memory.

The same problem occurs for Elt_method as well but is less serious since
only one CHARSXPs is allocated. Because my package is designed for sharing
a large R object. An allocation of the memory is undesired especially when
the data is read-only in the code(eg. print function). I'm not sure if
there are any solutions existed in the current R version, but I can imagine
three workarounds:

1. Change the behavior of the R functions and use get_element function
instead of Dataptr function. This would make the problem more
memory-friendly but still cause the allocation.

2. Return a vector of const char* in Dataptr method. It would be very
efficient and consistent with the return values of the other ALTREP types.

3. Provide an alternative CHARSXP. This might be the best solution since
STRSXP behaves more like a list instead of a string, so an alternative
CHARSXP fits the concept of ALTREP better.

Since I'm not an expert in R so I might post a solved problem. I would be
very happy and appreciate any suggestions regarding this problem.

Best,
Jiefei

	[[alternative HTML version deleted]]