This issue began with I posted a question to cats gitter - is there support for conversion of Boolean to Option values, like the option[A](a: A) method in Scalaz.
Two other example where people have/want-to enrich standard lib classes with extra behavior:
The scalaz.syntax.std package has a bunch more that could be supported if/when useful or requested, egs:
Opinion seemed to run against adding such "conveniences" into cats core in general, eg @travisbrown response. But in following discussion there seemed to be agreement they have value and for putting them somewhere in a new module or project (working title extra-syntax).
Our immediate goals are to answer:
What should the scope/charter of extra-syntax be? I'd say the primary goal is Improvement/enrichment of the standard library classes, with secondary goal increase familiarity & portability for Scalaz programmers.
The principle I stumble to articulate though is, when does code go into extra-syntax vs cats syntax?
Proposal:
Option => Xor) go into cats coreAnything else goes to extra, such as conversions between std types, or extra methods like option.cata.
Or is the distinction more about barrier-to-entry/level-of-consensus? If everyone agrees its central, it can go to cats core, if there's doubt its goes to extras? Not too keen on this, I'd prefer a more objective criteria ideally..
Should it be a new project or a new module? My feeling at present is that it'll prove to be pretty small, only the most valuable tip of scalaz.syntax.std will be requested, and so a module with cats is preferable to another project. Not a strongly held position however.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4