`vctrs` implementation not according to standard

[fabian-s]

• IIUC, vec_ptype2 methods are ONLY and simply meant to return (a prototype of) the (super)class of both inputs or throw an error if there is none, see https://vctrs.r-lib.org/reference/theory-faq-coercion.html#vec-ptype-:

  "Methods for vec_ptype2() are passed two prototypes, i.e. two inputs emptied of their elements. They implement two behaviours: If the types of their inputs are compatible, indicate which of them is the richer type by returning it. If the types are of equal resolution, return any of the two. Throw an error with stop_incompatible_type() when it can be determined from the attributes that the types of the inputs are not compatible." ours, however, currently implement or call concatenation methods, perform checks whether the two can be concantenated at all based on their content, etc.. this then causes weird and misleading messages and errors like:

> x <- tf_rgp(2, arg = seq(0, 1, length.out = 11))
> tfb_k5 <- x |> tfb(k = 5)
> tfb_k10 <- x |> tfb(k = 10)
> c(tfb_k5, tfb_k10)
empty or missing input `data`; returning prototype of length 0 
### this comes from vec_ptype2 ' attempt to establish a common superclass by generating empty prototypes, I think
Error in `map()`: 
ℹ In index: 1.
Caused by error in `tf_rebase()` at tf/R/rebase-predict.R:69:3:  
! Assertion on 'all.equal(tf_domain(object), tf_domain(basis_from))' failed: Must be TRUE. 
### this error comes from trying to concatenate the empty prototype to the first (top-level) argument  ?!??

• need to separate

  • the logic that establishes class hierarchies (ptype2) from
  • the logic for class conversions (cast) and from
  • the logic for concatenation (c, vec_c), which needs to check a lot more in our case than just whether the classes are compatible/castable in principle, but also common domain/basis, etc etc etc)

• functionality in tf_rebase is somewhat related to vec_cast but currently reuses none of the code

[fabian-s]

• may need vec_ptype methods to reduce objects to 0-length vectors that preserve their attributes?
• and then re-implement c.tf instead of relying on vec_c?

[fabian-s]

• should vec_cast use lossy_cast when doing tfd -> tfb.
• should tf_smooth
• should tf_rebase?