Yes, you are right that in a literal sense the port is not exact. Primarily, I wanted to have the freedom to use that trait parameter type as a building block for other types if I wished to.
See e.g. my 'Graph' implementation.[1] In it, I pass in the type of the vertex as a trait type parameter 'A'. In the 'Graph[A]' trait I also have an abstract type 'E' to represent the edge. 'E' is used in a couple of the methods.
Later I define a more specialised 'MapGraph' trait and refine the type 'E' to be a pair of 'A's. I couldn't have done this if I wasn't passing in the 'A' as a type parameter.
This leads me to believe that all things considered you get more flexibility from always using type parameters, not to mention somewhat better signal-to-noise in the code (getting rid of all the method type params), and also being able to use 'val's.
It isn't about freedom. If you are going to parametrize the entire trait, there is no longer any point to giving T a higher kind. As such it just adds noise and is bad style.
Actually I agree with you. In fact if you look at the 'UnbalancedSet' functor I define the type 'T' to not take any parameters. In the case of 'IntMap' it just happened that I missed that. So thanks for pointing it out. I'll make the necessary updates.
And using "def" is actually considered better Scala style in situations like this, exactly because it is more flexible. You can override a "def" with a "val" but not the other way around.
See e.g. my 'Graph' implementation.[1] In it, I pass in the type of the vertex as a trait type parameter 'A'. In the 'Graph[A]' trait I also have an abstract type 'E' to represent the edge. 'E' is used in a couple of the methods.
Later I define a more specialised 'MapGraph' trait and refine the type 'E' to be a pair of 'A's. I couldn't have done this if I wasn't passing in the 'A' as a type parameter.
This leads me to believe that all things considered you get more flexibility from always using type parameters, not to mention somewhat better signal-to-noise in the code (getting rid of all the method type params), and also being able to use 'val's.
[1] https://github.com/yawaramin/scala-modules/blob/8df0ec516629...