Reduce visibility of value member in the NonEmptyMap syntax

[TonioGela]

Simple fix for this annoying behaviour:

//> using dep org.typelevel::cats-core::2.10.0

import cats.data.NonEmptyMap

val nem: NonEmptyMap[Int,Int] = NonEmptyMap.of(1 -> 1)
val alsoNem: NonEmptyMap[Int,Int] = nem.value.value.value.value

The fix passes the Mima check, but ofc it will become impossible to explicitly call .value on NonEmptyMap instances (but that's what we want, right?)
Thanks to @reardonj for the solution

[danicheg]

It'd be nice to burn this out wherever possible at once. I recall the same approach is used for NonEmptySet.

[TonioGela]

It'd be nice to burn this out wherever possible at once. I recall the same approach is used for NonEmptySet.

I'm on it!

[TonioGela]

I noticed these for NonEmptyVector, NonEmptyList and NonEmptySeq

object NonEmptyVector {
  //...
  class ZipNonEmptyVector[A](val value: NonEmptyVector[A]) extends Serializable
  //...
}

but they seem more like implementation details for some other syntax methods (and I'm not sure they're user-visible). Shall we hide these constructors, too?

[reardonj]

I noticed these for NonEmptyVector, NonEmptyList and NonEmptySeq

object NonEmptyVector {
  //...
  class ZipNonEmptyVector[A](val value: NonEmptyVector[A]) extends Serializable
  //...
}

but they seem more like implementation details for some other syntax methods (and I'm not sure they're user-visible). Shall we hide these constructors, too?

Like, private constructor even? That does looks like an implementation detail.

 class ZipNonEmptyVector[A] private[data](private[data] val value: NonEmptyVector[A]) extends Serializable

[TonioGela]

Like, private constructor even? That does looks like an implementation detail.

 class ZipNonEmptyVector[A] private[data](private[data] val value: NonEmptyVector[A]) extends Serializable

I'm not sure I follow. You're suggesting me to either apply this method or you're thinking out loud if this is an implementation detail and we should leave it like so?

[reardonj]

That the class is an implementation detail and the whole thing could be hidden. Hmm; I guess package private can even go on a class.

[satorg]

Nice catch, thanks!

I feel we should merge it – exposing "self" values in extension-like classes is hardly a good idea in general.

[TonioGela]

Nice catch, thanks!

Thank you

I feel we should merge it – exposing "self" values in extension-like classes is hardly a good idea in general.

I've tried to spot them all, but we can't be 100% sure

[satorg]

Let me go ahead and merge it not awaiting the second approval. It seems to be a straightforward but still quite important change, so if Mima is happy, I am more than happy too.

[TonioGela]

Let me go ahead and merge it not awaiting the second approval. It seems to be a straightforward but still quite important change, so if Mima is happy, I am more than happy too.

Thanks @satorg