On Thu, 17 Dec 2020 18:28:00 +0000, you wrote:

| I can agree that authors copied Java style a bit overzealously, but 
| we have what we have.

It's pervasive to the point of being pernicious.

| C API would be good, too, and IMHO it should not be that hard to 
| provide it with the current codebase, though it might simply require 
| a lot of typing.

Yes, there's nothing wrong with implementing the library in C++ while
presenting a C interface.  Apart from the "lot of typing" ( by which I
assume you mean translating method calls to external functions), there
will also be a need to define error codes and translate exceptions to
these.  
 
| Besides, regardless of its final shape I guess the project would 
| benefit from simplifying it, e.g. by replacing platfrom-specific 
| threads with std::thread.

Yes, the code base should be upgraded to take advantage of the vast
increases in standardization that came in with C++11 and successors. 

| If the "javaisms" are to be reworked into modern C++ is a matter of 
| taste, but if it's possible to be done step by step I guess it 
| should be considered

I think it's more than a matter of taste. The Javaisms are a definite
detriment and should be reworked.  This is more than just purging
gratuitous heap allocation, the most egregious offender.  It extends
to interfaces as well: e.g. presently, covariant return types are
avoided because Java doesn't have them, which is a silly reason.  
There is a lot of gratuitous inheritance (Closeable, Stoppable, etc.)
which serves no purpose other than code bloat. Another purge target is
the profusion of #include-s, which seem motivated by an analogy with
Java's import statement.  And so on.

| @Mike thanks for information on how to contribute, hopefully it will 
| become handy soon :)

Seconded. :-)

-- 
:ar

Reply via email to