On Mon, 11 May 2026 18:01:01 GMT, Kevin Bourrillion <[email protected]> wrote:
> Existing "at-index" methods tend to just end with "-At" (like > String.charAt()). (I personally like ends-with-preposition naming, at least > for single-arg methods like this.) In many ways this would be preferable, but I think @minborg did some searching and found that it would result in a bunch of conflicts. > In fact, j.u.Vector names this very same method removeElementAt, but that > seems unnecessarily wordy. The fact that j.u.Vector will end up with three > methods that do the same thing might be sad if anyone really cared about > j.u.Vector anymore. Yeah. On the one hand, if we wanted to minimize the overall number of methods in the system, then using `removeElementAt` would do that; it would accept `j.u.Vector` as setting a precedent here. Unfortunately it would be a _bad_ precedent as the collections framework (JDK 1.2) deliberately broke with some of the precedents set by the legacy collections from JDK 1.0 such as `Vector` and `Hashtable`. In particular, using `element` in the names of the `Vector` methods was _not_ carried over into the Collections interfaces. We don't want to start doing that now, 28 years later. There are a couple of other methods in `List` that already use "index" such as `indexOf`, `lastIndexOf`, so at least this doesn't introduce an entirely new term. But yes, `removeAtIndex` is a compromise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31064#issuecomment-4423503428
