On Tue, 25 Oct 2016 10:32:20 -0700, Gary Gregory wrote:
On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann
<jochen.wiedm...@gmail.com>
wrote:
Honestly, I really wonder why all this stuff has to fork yet another
commons component. IMO, CM could just have been changed to emit
multiple jar files with no need for other components. No need for
discussions, no need for new repositories in Git, no need for new
stuff in Jira. Or, to put it different: Less to maintain.
+1
I am against this constant spinning out.
I've argued that the original mistake was to let CM extend beyond
the stat toolbox it was when the component was created.
Please refer to the ML archive.
The fix is to separate what was never actually a coherent whole
(from the contents, programming style, and management POVs).
If you are against something, you have to provide a technical
argument. There can be none (see previous paragraph).
This discussion could have been the business of a new TLP (as
promoted by James Carman).
This has been REFUSED.
People are willing to actively create, maintain and use an
eco-system of components on which they are more expert than
anyone else here.
And people who never read a single line from the CM codebase
would just be "against" it?
Gilles
Gary
On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill
<ericbarnh...@gmail.com>
wrote:
> As the recent contribution shows the commons-math complex library
remains
> quite useful to many applications.
>
> Following in the footsteps of commons-rng, commons-complex seems
like a
> good next component of math to spin out and actively maintain. I
am
willing
> to oversee and maintain the project.
>
> It may be that as I get into it, complex will have dependencies
that more
> properly belong in a core library. I propose to just get started
on the
> library and sort these issues as they come up.
>
> I would take the following positions as regards this library:
>
> - Add syntactic sugar so that typical C++ calls are compatible:
yes
> - Keep completely backwards compatible: yes
> - Follow the C++ architecture including an Imaginary data type
with its
own
> behavior: no
> - Like C++, incorporate complex typing other than double: no
>
> -Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
