Hello Marc
No refactoring has been done. My email was suggestions waiting for comments.
Making a class package-private in just one option. If not practical, an
other option is to move in an internal package, which was also proposed
as an alternative in my email.
It is okay if an API need more though - no problem with that. In such
case, moving them to an internal package give you more freedom - this is
not a dismiss of your work.
The reason is that we would like to prepare a release in the upcoming
weeks. In theory, everything in public API after the release can not
move anymore (we are not always strict about that, but we do our best to
achieve this goal). By moving the classes in an internal package, you
keep all freedom to modify them as you want even after the release.
Martin
Le 16/12/14 15:42, Marc Le Bihan a écrit :
> 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
>
