ListOf<T> class

[kevinushey]

ListOf<T> is like a List, but subsetting it should return elements of type T and hence avoid having to do casts. It was initially motivated by @romainfrancois.

Suppose we have:

typedef ListOf<NumericVector> NVList;
NVList x;

• Can we enable lvalue differentiation, rvalue differentiation, and member functions? E.g. we would like to be able to do both of these:

a. x[0] = x[0] + x[1];
b. x[0].attr("foo") = "bar";

We currently use the ListOfProxy to handle lvalue and rvalue differentiation, but the ListOfProxy object generated does not have access to these methods. Is there a clean way that we can get any methods available for a NumericVector on the proxy object returned by x[0]?

• When constructing a ListOf<T>, should we check / coerce elements to T, or trust the user to do it? E.g. if I construct a ListOf<T> from a List should those elements be converted to T on insertion? Or should these be subclasses e.g. StrictListOf...

[romainfrancois]

I think operator[] should return a T and ListOf should definitely have an operator T.

As an example, the way it is currently implemented failed my expected usage in dplyr. (I've worked around this).

I think there should be a collection of classes offering different behaviors. In dplyr currently we have :

• FilteredListOf: In the ctor, we loop calls to is<T> and fill an std::vector<int> with indices that really can be considered as T. https://github.com/hadley/dplyr/blob/master/inst/include/tools/FilteredListOf.h
• StrictListOf : In the ctor, we loop around with is<T> again, and when it is false, we throw an exception. https://github.com/hadley/dplyr/blob/master/inst/include/tools/StrictListOf.h

Also, I don't think ListOf or whatever variation on it should not derive from List but rather contain one so that we can micro select exactly what interface we allow. Extending List gives you more interface for free, some you want, and lots you don't necessarily want.

[kevinushey]

How would operator T work with a ListOf (which would contain multiple Ts)? You mean e.g. (suppose list is a private List)

operator T() const {
    return as<T>(list[0]);
}

That seems awkward?

[romainfrancois]

Ah yes. Sorry, I meant that operator [](int) should return a T

[romainfrancois]

An alternative way to get access to methods of T but still have the differentiation would be to use something like this syntax: x[0]->attr("foo"), i.e. define typical smart pointer operators. But I'd prefer that operator[] directly returns a T. You can always use some other name for lhs use, e.g. x.set( 0, ...) or use another overload of [] e.g. x[_,0] = ... or move the proxyness out, i.e. lhs(x)[i] = ...

[kevinushey]

How might we implement sub-assignment in this scenario? E.g. ignoring ListOf and just thinking about Lists, for now,

#include <Rcpp.h>
using namespace Rcpp;

// [[Rcpp::export]]
List test(List x, NumericVector y) {
    NumericVector first_elem = x[0];
    first_elem = y;
    return x;
}

/*** R
test( list(1), 4 )
*/

just returns list(1). Any ideas on how we could write this so that the assignment of y to first_elem would also change x?

Alternatively, I think just using set or lhs as you suggest would work well enough.

[romainfrancois]

I don't think what you want should be the desired behavior. When you do first_elem = y I would not expect at all that this would modify x. For this to work with List, you'd have to retrieve the first element not as a resolved class but as a proxy somehow. So more something like: List::Proxy first_elem = x[0] ; first_elem = y ;

[kevinushey]

Yeah, you're right. I had this mixed up since doing something like SEXP first_elem = VECTOR_ELT(x, 0); REAL(first_elem)[0] = 4; would modify x, but first_elem = y wouldn't.

Thanks for the discussion; I'll modify the class with your suggestions.

[romainfrancois]

I think ListOf<T> gives too much power to is<T> as the thing that accepts something or not. For example you might accept a list of either numeric or integer vectors, ...

Have a look at this commit in dplyr: tidyverse/dplyr@8beadcf

The idea is that ListOf would look like:

template <typename T, typename Valid = IsOf<T> >

where IsOf would delegate to is<T> :

template <typename T>
struct IsOf {
inline bool operator()(SEXP x){ return is<T>(x); }
} ;

This way, by default you'd still use is but you have the composability to govern what it means to be accepted in the list.

[romainfrancois]

Also perhaps idea from this one: tidyverse/dplyr@8ac298f

Where the validator class can also explain what's wrong with the why_not method.

[romainfrancois]

This gets even more fun when you think about this with C++11 in mind, we could imagine that the validator be a lambda, e.g. :

ListOf< DataFrame, [](DataFrame df ) { return df.nrows() > 4 ; }> dfs ; 

If we wanted e.g. to make a list of data frame that have at least 5 rows. Not sure a lmabda inside a template spec is allowed, but there could be ways around this, e.g. a free function similar to make_pair:

auto list = make_ListOf<DataFrame>( data, [](DataFrame df){ return df.nrows() > 4 ; } ) ;

where type deduction would happen with type deduction of parameters of make_ListOf. Anyway, perhaps we should rather discuss this here: Rcpp11/Rcpp11#95

[coatless]

The ListOf<T> was created under commits 5c23627, 2e52627, and ce5d157.

Please close. (Tagging #506)