Hello Martin,
Currently the Database class only has for public methods :
public Charset getCharset()
public int getRecordCount()
public ArrayList<FieldDescriptor> getFieldsDescriptor()
public File getFile()
public int getRowNum()
and to allow it to be used from ShapeFile class, these ones :
public void close()
public boolean isClosed()
public void loadRowIntoFeature(Feature feature)
and for being used from DBFRecordBasedResultSet class :
public HashMap<String, Object> readNextRowAsObjects()
Eventually, the close, isClosed, loadRowIntoFeature, and
readNextRowAsObjects will disapear because our refactoring will lead to a
more stable/nice state.
Until this time, I suggest only to put a @deprecated annotation on these
four methods and on the @Deprecated javadoc mention that they be removed
soon during next refactoring and that they will not be seen in 0.6 version.
I think we will be find with programmers using our API that way.
For FieldDescriptor class these methods exist :
public int getDecimalCount()
public int getLength()
public String getName()
public DataType getType()
But I see, you are right the members being public. I didn't refactor
that when I saw them.
Let me try to do a change on them this morning.
"Various numerical codes internal to the DBase format" :
codepage values are not visible, else I've done a mistake ?
I think that if they were I wouldn't be so trouble some. The DBase Header
could be public (even if it will not be), because it's the Dbase format, and
if a developper needed these metadata coming from the end of the 80's he
could find them by our API).
MappedByteBuffer is not public but has package level, and won't be shown to
users. But I understand what you mean.
For Shapefile object, I have refactored nothing :
Do you want me to try to put all members private and put only some
public getters on them ?
Regards,
Marc.
-----Message d'origine-----
From: Martin Desruisseaux
Sent: Monday, December 22, 2014 6:55 AM
To: Apache SIS
Subject: Action for a SIS 0.5 release?
Hello all
Which action should we take regarding the Shapefile module for a SIS 0.5
release? Choices are:
1) Release with the shapefile module as-is.
2) Omit (again) the shapefile module for the release.
3) Review its public API before release, e.g. as in SIS-185 [1].
I would like to avoid 1 because the current public API does not yet
follow the encapsulation principle. Currently, we expose many internal
details. Examples:
* String or dates stored as array of bytes
* Addresses to fields in memory (maybe a legacy from C/C++)
* Undocumented things like "DBase+ Lan Reserved 2"
* Various numerical codes internal to the DBase format
* Objects used by the implementation for performing I/O operations (e.g.
MappedByteBuffer)
Since SIS is a library aimed to be used by applications that we do not
control, every public API is likely to be used by someone somewhere.
Exposing those objects publicly would mean that we commit to keep them
in the future. I don't think that this is the intend...
Martin
[1] https://issues.apache.org/jira/browse/SIS-185
