You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately we weren't aware of Derive4J, this is the first time we've heard about it. It definitely looks like a really versatile library that covers a lot of things that we don't, in particular the optics and other more advanced FP concepts look very attractive. I'll definitely add Derive4J to the Alternatives section.
The reason we wanted something like dataenum was in order to make pure functions used with Mobius less verbose using pattern matching, and it's primarily the exhaustive pattern matching we are interested in. We had partial matching support in dataenum for a while during initial development, but we removed it in favour of simplicity.
In general, simplicity really was our goal with dataenum, both in terms of API and generated code. Our primary target is Android so there are some considerations like method-count and code size, but it looks like Derive4J is quite configurable in that aspect.
In our particular context, catering to programmers with a non-FP background is also a concern, so if I was to say anything against Derive4J I suppose it would be that it maybe has too many features. But I don't think that's a very strong argument, and it's quite likely we wouldn't have created dataenum if we had known about Derive4J.
It'd be really interesting to hearing your thoughts about dataenum, especially since you've been working on the same problem and know the domain!
Activity
[-]add Derive4J to Alternative section[/-][+]add Derive4J to Alternatives section[/+]togi commentedon Mar 19, 2018
Unfortunately we weren't aware of Derive4J, this is the first time we've heard about it. It definitely looks like a really versatile library that covers a lot of things that we don't, in particular the optics and other more advanced FP concepts look very attractive. I'll definitely add Derive4J to the Alternatives section.
The reason we wanted something like dataenum was in order to make pure functions used with Mobius less verbose using pattern matching, and it's primarily the exhaustive pattern matching we are interested in. We had partial matching support in dataenum for a while during initial development, but we removed it in favour of simplicity.
In general, simplicity really was our goal with dataenum, both in terms of API and generated code. Our primary target is Android so there are some considerations like method-count and code size, but it looks like Derive4J is quite configurable in that aspect.
In our particular context, catering to programmers with a non-FP background is also a concern, so if I was to say anything against Derive4J I suppose it would be that it maybe has too many features. But I don't think that's a very strong argument, and it's quite likely we wouldn't have created dataenum if we had known about Derive4J.
It'd be really interesting to hearing your thoughts about dataenum, especially since you've been working on the same problem and know the domain!