Hello,
Just a few comments, I believe classes and methods should be hidden as
much as possible unless they can be used for other purpose.
- DBF file are sometimes found with other format, not only shapefile, so
having dbf utility classes visible could be a good thing if they can be
used separately.
- Same for geometry, the same encoding format is also used in esri
geodatabases.
- I also agree that 'making it work' is more important then 'make it
clean' , at least until it works and is tested.
- But I agree with martin too, what is internal mechanics should not be
accessible when everything if finished.
Johann Sorel
On 16/12/2014 07:42, Marc Le Bihan wrote:
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
