As @TimTaylor first pointed out in #83, refactor() overwrites the class with the reset result of factor. This affects a bunch of methods downstream of refactor() like lvls_expand(), lvls_reorder(), fct_lump_n(), etc.
Because refactor() sometimes needs to set ordered in the class list, it's not as simple as ignoring the class of the new factor. Instead, if ordered is being toggled off, it drops "ordered" from the original class list; if it's being toggled on, it adds "ordered" to the original class list; if nothing is changed it uses the original class list. As a result, all the subclasses in the original factor propagate to the result, instead of getting lost.
The tests in lvls-test.R demonstrate this functionality.
As @TimTaylor first pointed out in #83,
refactor()overwrites the class with the reset result of factor. This affects a bunch of methods downstream ofrefactor()likelvls_expand(),lvls_reorder(),fct_lump_n(), etc.Because
refactor()sometimes needs to setorderedin the class list, it's not as simple as ignoring the class of the new factor. Instead, iforderedis being toggled off, it drops "ordered" from the original class list; if it's being toggled on, it adds "ordered" to the original class list; if nothing is changed it uses the original class list. As a result, all the subclasses in the original factor propagate to the result, instead of getting lost.The tests in
lvls-test.Rdemonstrate this functionality.Cheers!