For package - privated classes, I absolutely disagree.
There will be a big drawback : in order to use them, all the classes split
in the metadata, resultset, sql and other packages for dispatching and
readability would have to return to the org.apache.sis.storage.shapefile
package : else the compiler will cause compilations failures due to
visibility. This would result in a package containing 50 classes. And I
don't want that. Especially because the JDBC driver only begins, and at
least 50 or 100 new classes will appear, for insertion, update, deletion
handling, better parsing, etc.
By the way, the Mapped bytes buffer and other classes will be changed one
way or another during insert / update / delete operations because they
cannot stand these operations.
The goal of AbstractAutoChecker is not only the jdbc package, but I cannot
explain it yet really clearly.
While I try to set main features for SQL (especially this time : Insert /
Update / Delete, and better parser for multi-condition request), I would
like no one attempt to refactor the code in any way, except if a bug
appears, even if it causes to show temporary a public class or causes some
performances leaks (what is not important : it's the first time we are
querying databases !). They are minors troubles compared to what is
attempted and will only be corrected at the end of the process.
Attempting to put private-package classes, final methods, or to achieve
performance by doing special refactoring now, would immediately stop my work
:
I have set the packages and the classes in a way to allow them to grow and
change quickly, be able to refactor them easily, and especially : split and
split them again. What would be the gain of having done many minors changes
and these optimizations for technician pleasure (because private-package,
final methods and so are that : they have no use at the end, they are only
done to loose time, most of the time), if it's not to have some really
useful features that we can show to users ?
I don't want any changes now. Especially for these little matters.
My goal is to help to finish a reliable geomatic API. Not to loose myself in
technician dreams ! I don't want to make internal optimizations now. I focus
on progressing, testing, checking. Not on keywords !!!!!
Of course I can't be 100% compliant to all the rules known. No one can be.
Because they are some Java Divas who are creating these rules all the time
in order to sell books without considering the trouble they are generating !
I hope that the way I write 90% of the source code is good, that's all,
provided it is 100% free of bugs. Trying to be 100% compliant with standards
transforms any project to a crystal where no one can no more move : there
will always be a little thing you have forgotten that a book said at page
142. They will always be someone that could change one line, and another,
and another. But while doing this, end user see no additional useful
features. It's a trap !
Please stop busting every line code I am writting. I told you earlier that
it was a long term development. Of course it is ! It is even hard to find
the way to accomplish the next steps. Don't ask for changes for little
things like that !
It would really destroy the work done. For nothing.
Don't attempt to make refactoring immediately. We need to succeed in
implementing features first. If they are tested, working and showable, it's
fine. It will be easy to refactor and profile at the end when all the
non-regression test will be there to ensure that you can go from a slow
version 1 to a fast version 2. But first : I have to succeed in slow version
1 and compliant only to 90% of the Java standards.
Regards,
Marc.
-----Message d'origine-----
From: Martin Desruisseaux
Sent: Tuesday, December 16, 2014 4:46 AM
To: Apache SIS
Subject: Preparing for SIS 0.5 RC
Hello all
I would like to prepare a SIS Release Candidate (RC) soon. But before
doing so, I would like a consolidation of the ShapeFile API. This does
not affect the internal JDBC implementation, only the public API (even
if incomplete, we can complete later). The package is:
https://builds.apache.org/job/sis-dev/javadoc/org/apache/sis/storage/shapefile/package-summary.html
My suggestions:
* Make FieldDescriptor and FieldDescriptors class package-privated,
because they seem to be implementation details internal to the
Shapefile reader.
* Make DataType and ShapeTypeEnum package-privated for now, because I
think that they may be partially replaced by more generic
constructs. For example the categorization of geometries in point,
polyline, polygon, etc. is not specific to the Shapefile format.
* Make Database a package-private class, or move it in an internal
package for now, as it depends on AbstractAutoChecker (which we
suggested to move in an internal package too) and to give us more
time to review its API:
o For example the current Database API provides a public
getByteBuffer() method which returns the MappedByteBuffer used
internally by the Database. I think it is quite dangerous to
expose publicly such Database internal.
* ShapeFile should extend DataStore, and its fields should be private.
What do you think?
Martin
