Re: Strategy for Updating Public API Changes

2016-12-27 Thread Anthony Baker
I agree with Darrel. I’m not a big fan of the current Fn API for a variety of reasons, not least of which is the annoyingly inconsistent use of generics that Ayssa was trying to fix. I think a newer take on this API should include support for lambdas and Stream / Reactive patterns. Anthony On D

Re: Strategy for Updating Public API Changes

2016-12-27 Thread Anthony Baker
I agree with Darrel. I’m not a big fan of the current Fn API for a variety of reasons, not least of which is the annoyingly inconsistent use of generics that Ayssa was trying to fix. I think a newer take on this API should include support for lambdas and Stream / Reactive patterns. Anthony

Re: Strategy for Updating Public API Changes

2016-12-23 Thread Michael Stolz
+1 that's exactly what deprecation is for -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Dec 23, 2016 2:37 PM, "Darrel Schneider" wrote: > If changing an external API would break existing applications I think it > would be better to introduce a new API that ha

Re: Strategy for Updating Public API Changes

2016-12-23 Thread Darrel Schneider
If changing an external API would break existing applications I think it would be better to introduce a new API that has the improved behavior. Deprecate the old external API with a comment saying that you should use the new one instead. Then in the next release we can remove the old external depre