Naming conventions for collections API

Recently I’ve noticed that collections API names in Scala are a bit inconsistent: there are methods with -ed like sorted, appended and prepended, but also the ones without -ed like reverse, filter, map and more bizarrely sortWith and sortBy (not sortedWith and sortedBy).
In a similar vein we also have filterInPlace, mapInPlace and sortInPlace.
So it seems that the verbs are preferred rather than adjectives with -ed.

However, I couldn’t find any definitive guidelines on this naming preference and on what naming scheme to use in my own collections for similar methods and in general.

So I was wondering what are the rules for choosing -ed vs. no -ed?
Or perhaps sorted was just unfortunately named at the time, and will at some point be replaced by sort?

6 Likes

A quick answer is that -ed means a new collection is produced (possibly with structural sharing).

But many traditional names are traditionally functional and operate on immutable data, such as map.

So the mutable version is InPlace.

Prepend to something mutable is prepend, prepend to something immutable is prepended.

My sense is that they paid attention to the naming issue and they will never offer the ambiguous sort. I’m only comfortable with API I use frequently. Thank goodness for map and filter and flatMap.

Here is one commit for prepended: https://github.com/scala/scala/commit/1fc1a4de604e9e616f4c9c6aad75ca4138d8793a

It looks like you hit a blame wall because the work was done in a separate repository, so archaeology would require extra digging.

Autocomplete on ListBuffer asks if I want to see 220 completions; List is only 184. So maybe it’s a way to get me to use immutable data structures.

5 Likes

@julienrf do you recall if there is any kind of documentation or on-the-record discussion about this?

No, I don’t know, sorted, sortWith, and sortBy were already there in 2.10 (and maybe even before that) :slight_smile:

I agree that the naming scheme is not consistent…