One reason I don't want to work on this is because the appropriate
action depends on what "length(x)" is intended to mean. Currently for
POSIXlt objects, it gives the physical length of the underlying basic
type (the list). This is the same behaviour as we have for matrices,
data frames and every other object without a specific length method, so
it's not outrageous.
The proposed change is to have it return the logical length of the
object, which also seems quite reasonable. I don't think matrices and
data frames have a "logical length", so there would be no contradiction
in those examples. The thing that worries me is that there are probably
objects in packages where both logical length and physical length make
sense but are different. I don't have any expectation that length(x) on
those currently is consistent in which type of value it returns.
If we were to decide that "length(x)" *always* meant logical length,
then we would have a problem: matrices and data frames don't have a
logical length, so we shouldn't be getting an answer there. Changing
length(x) for those is not acceptable.
On the other hand, if we decide that "length(x)" *always* means physical
length, we don't need to do anything to the POSIXlt or matrices or data
frames, but there may well be other kinds of objects out there that
violate this rule.
We could leave the meaning of length(x) ambiguous. If you want to know
what it does for a POSIXlt object, you need to read the documentation or
look at the source code. As a policy, this isn't particularly
appealing, but I could probably live with it if someone else did the
research and showed that current usage is ambiguous.