-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Imports unification and other syntax changes #117
Comments
@FunFunFine not sure this does really makes a lot of sense, as comparing to cats/cats-effect - we don't have much to import hence not sure feature of being able to "selectively import something" is useful As drawback - there is added maintenance and runtime cost of flexible solution |
My proposal is more about |
With upgrade to CE3 and changing package to I've had numerous times, when I had to lookup which is the required import, thus having something common, very similar to Cats and Cats-Effect approach, would be very welcome usability improvement. Nobody is going to remove the ability to have explicit single given imports. |
There is a little inconsistency regarding imports in the library: while any other library (e.g. cats, cats-effect & tofu) import their syntax by
import lib.syntax.something._
andimport lib.syntax.all._
,cats-helper
does it in its own unique way byimport com.evolutiongaming.SomethingHelper._
.It kind of slows down the adoption by newcomers, because they can easily miss that those syntax objects even exist, so I would like to propose to change this import scheme to be the same as in cats. WDYT?
Another thing I would like to discuss here (I don't think it is worth creating a separate issue for that) is the pollution by
apply
methods. One can easily find such code incats-helper
(e.g. Blocking, FromFuture):Not only that it just doesn't work to call it like
Something[F](thing)
because of double apply andthing
being treated as an explicitly passed instance, but IntelliJ IDEA often fails to find usages or asks if I want to go to the instance or to the method. In other words, it is inconvenient. So my proposal is to add alternative methods names with the possible deprecation ofapply
methods.I could get this done, but I would like to see some discussion here. Are those proposals any good?
The text was updated successfully, but these errors were encountered: