Easing friction from collection name conflicts with the standard library

[andreascasapu]

Currently, there is some noticeable friction with introducing vavr in an existing codebase due to naming conflicts with the standard library for common collections such as List, Map, etc. In my experience, this has been one of the main reasons for pushback when trying to integrate vavr in an existing codebase, and I do agree that it causes issues with:

• Making it harder to migrate bit-by-bit by requiring that the entire file is migrated at once, or that the file is split in non-vavr and vavr halves during the transition.
• Making it somewhat confusing for newcomers that expect List, Map, etc. to refer to the standard versions instead of the vavr ones. This is even more so if different files use different versions, or if one file mixes vavr and non-vavr collections.
• Making it more difficult to ensure consistency in code review. While the two sets of collections looks different when used in more complex cases, they look pretty similar in usage for simple cases. Hence, extra care is required to double check which one is being used during code review.

In my experience, the above makes adoption harder than it needs to be, since people are hesitant to deal with the confusion/inconsistency in an existing code base. In the case of a new project, everyone needs to be on board to essentially replace the standard library with vavr and be vigilant about not mixing them.

I made this issue to have a discussion about easing this friction. In particular, the people that I have talked to feel that it would be a lot easier/less surprising/less error prone if the vavr variants had a slightly different name, and I tend to agree. For example, if the collections were called VList, VSet, VFuture, etc. it would be clear which one was being used. For values like Option, Either, Try, etc. that already have different names, this is not an issue, but it might be worth using the same naming convention throughout.

[Vyacheslav-Lapin]

As I understand it, Vavr shares a common geniology with Scala collections, and their names are taken from there. However, some collections taken “as-is” are considered obsolete in modern Scala - for example, Stream was replaced by LazyList quite a long time ago.

I think it would be a good idea to bring the Vavr collections in line with the latest Scala collections in terms of names and maybe even features. Partially it would solve this problem - io.vavr.collection.Stream would not be confused with java.util.stream.Stream.

As for VList, VSet and VFuture - it is more difficult to say here...

[andreascasapu]

Yeah, I was aware of Scala having been used as a bit inspiration. Personally, I don't have a strong opinion on either the names, or even if the name approach should be taken. It was just an idea (and the only one that I could think up so far). I am mainly interested in the result, which is that vavr types can live and be used alongside java ones without conflicts.

I suppose it would be possible to subclass a bunch of things on the client-side as a poor substitute for type aliasing, but that both feels dirty and might not always play nicely with type inference due to being different types.

I am not sure what the best way to achieve this would be, but I would love to be able to use vavr more in my work, and this has been the biggest hurdle towards that in my situation.

[pivovarit]

First things first, moving this to Discussions :)

Secondly, this is a great point. There are two types of existing data structures:

• those where a non-conflicting alternative exists (think Stream -> LazyList)
• the rest (Lazy/Set/Map) - this requires either a lot of creativity or coming up with vavr-specific identifier

I like the idea of prefixing existing collection names with V, but I think we need to gather more ideas. We only have one shot at this. This could be introduced into the existing codebase by relying on aliases