It seems like the only reason similar would be called on Array{<:CategoricalValue} with a new eltype of CategoricalValue means the user apparently explicitly wanted an Array (otherwise, it would have been called with an AbstractRange typeof(1:1) for instance). It seems like this package might be not following user expectations here, which is also appearing to cause many invalidations during loading, leading to worse precompile results across the Julia ecosystem. I think we should delete these extra similar methods, so that requests for a similar object to a Base Vector does indeed return some similar Vector to the original. But keep the methods for typeof(1:1), so that collect with a CategoricalValue does still get the CategoricalArray as intended, when the user has not otherwise tried to explicitly ask for it to return a Base.Vector type as the argument to collect_to?
It seems like the only reason
similarwould be called onArray{<:CategoricalValue}with a new eltype ofCategoricalValuemeans the user apparently explicitly wanted anArray(otherwise, it would have been called with anAbstractRange typeof(1:1)for instance). It seems like this package might be not following user expectations here, which is also appearing to cause many invalidations during loading, leading to worse precompile results across the Julia ecosystem. I think we should delete these extrasimilarmethods, so that requests for asimilarobject to a BaseVectordoes indeed return some similarVectorto the original. But keep the methods fortypeof(1:1), so that collect with a CategoricalValue does still get the CategoricalArray as intended, when the user has not otherwise tried to explicitly ask for it to return a Base.Vector type as the argument tocollect_to?