As discussed there, I think it would be a good idea to have a library called extras in the Scala Platform that hosts small and useful utilities that improve the Scala developer experience. The one that @yangbo proposes fits in this definition – converters from functions and partial functions to extractors. This helps the reusability of already defined functions and saves some lines of code. Another candidate would be enableIf.
An idea would be to add all these small utilities in one repository and create a network of maintainers that care about them. As these utilities are supposed to be small in size, sources and documentations would be shared and defined in sbt subprojects. There would be a extras sbt subproject that will depend on all the other subprojects and would be published in the Scala Platform as an empty artifact. Each utility would also be published so that users have a fine-grained control over what they pull in in their projects.
Why should we do such thing? Small libraries are difficult to find. They are hosted in different GitHub profiles and finding them is painful. Often, they are unpublished because they are so small that the library authors don’t see any value in publishing them and writing some docs or buzzwords to enhance searchability – they just write it for them and it’s understandable that they don’t want to spend too much time on them. If we have such a package, we would solve all these problems and lay the ground for new small utils that may show up in the future. People interested in these utilities could add them to extras and help maintain them.
I would like to discuss the value of this idea with the Community and hopefully identify potential microlibraries that would be the perfect fit for this extras package. They could be from a DIY util that you use daily in your organization to any random library that you’ve written because the standard library didn’t provide X functionality.
This package would be similar to Twitter Util. We should also define how it differs from it and probe potential ways of collaborating with the Twitter guys.
It’s not a bad idea, but could easily become enormous and unfocused – a big heavy grab-bag of so much random stuff that nobody can find anything and it winds up pulling in tons of extra libraries with no rhyme or reason. I think that would be a net negative.
So basically, I think this would be more useful if there was more definition to it. What kind of micro-libraries would it include?
I can see the outlines of a theme here – the converters, extractors and enableIf are all essentially enhancing the standard language and environment, but not actually providing functionality. I think if we can nail down that theme a bit more concretely, that may make it easier to identify what does and doesn’t belong in here, and will probably make it more appropriate to the standard Platform.
(But I suspect that it’s going to be an ongoing struggle to identify crisp lines of what belongs. I mean, Shapeless also qualifies by the definition I just gave, and I doubt it’s what you’re intending. So you need to think about both what it means to be a “microlibrary”, and what the parameters of these “extras” are.)
Agree. Junk Drawer is not a good design pattern. The doc says stable collection of libraries with widespread use … if someone creates such a library and it gains widespread use then sure, it can apply to become part of the platform. Until then it’s experimentation which isn’t (as I understand things) what this exercise is about.
My idea was that utils included in this package would need to be voted on by the Scala Platform Committee, and this would be done based on the rules that the Scala Platform process specifies (including the one you’ve linked to). There would be noJunk Drawer. The utils included in this package would need to be useful and used by the Community.
Yes, I agree. I’ll think about this in the next days and try to formalize this definition. In the meanwhile, let’s see what people would like to see in this package.