Why does to_a and to_ary behave differently in subclasses of Array?

Question

If you have a subclass X of Array, then doing X#to_a returns an array object, while doing X#to_ary returns an x object.

While I understand that to_a means "I can be changed into an array", while to_ary means "I behave like an array", I don't understand why the former implements a change of class while the latter doesn't.

Also, isn't returning a subclass of Array sufficient for to_a, under the Liskov Substitution Principle?

Answer 1

Is "because that's the way it's defined to be" sufficient?

to_a

Returns self. If called on a subclass of Array, converts the receiver to an Array object.

to_ary

Returns self.

Probably not, so here we go into the rabbit hole.

Beyond the fact that the documentation definitively states that this is the way it is, the reasoning is perhaps only truly answerable by Matz, et al.

Digging around though it would seem that to_ary is used when implicit type conversions occur. Its use for implicit conversions seems to be echoed in this feature request as well. In other words, if an object responds to to_ary, then it should be treated as an Array, and it is used in this way internally. Thus to_a would be for when you (explicitly) want an Array and not some subclass.

Yes, returning a subclass would still satisfy LSP (assuming the subclass does not decide to radically change the behavior of Array such that it wouldn't be), but the principle only states that a subclass may be substituted for its base class, not that it needs to be. I'm not really sure that matter here anyway, though, since you're calling to_a your explicitly asking for a different object (to go along with the reasoning about implicit conversions above) and thus you're saying you don't want a substitute object type.

Answer 2

As a general rule, the implicit conversions are automatically called by the interpreter, and they are intended to only convert things that are very much like the type that was required but not found.

The explicit conversions, however, can be called on disparate types as long as there is some way to get from point a to point b, even if that involves some sort of polar route or a detour.

So you simply have more freedom for a leap with to_a, but I agree that it seems like X should be good enough.