[
https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171982#comment-14171982
]
Martin Desruisseaux commented on SIS-180:
-----------------------------------------
On the star imports, there is no absolute rule. This is a compromise depending
on the amount of imports. If there is only 3 or 4 classes to import from a
package, enumerating them does not pollute the code so much. But if a package
is imported almost entirely, then a star import makes lot of sense. Between the
2 the frontier is not clear.
The reason for enumerating the imports explicitly is to protect the code
against name collision between two packages. The problem may not exist at the
time of writing a code, but appears later when new classes are added in the
imported packages. An historical example is the name collision between
{{java.awt.List}} and {{java.util.List}} when the later has been added to Java
1.2: some code using start imports that compiled under Java 1.1 did not
compiled anymore under Java 1.2.
However I agree about long list of imports not being easy to read - there is a
balance somewhere between enumerating everything and all start imports.
> Place a crude JDBC driver over Dbase files
> ------------------------------------------
>
> Key: SIS-180
> URL: https://issues.apache.org/jira/browse/SIS-180
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
> Affects Versions: 0.5
> Reporter: M. Le Bihan
> Assignee: Martin Desruisseaux
> Priority: Minor
> Fix For: 0.5
>
> Attachments: src.zip
>
>
> It would be useful to be able to query DBF content through SQL.
> But there are no free drivers available for the old _Dbase 3_ format.
> The first step is to create short implementations of _Connection_,
> _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our
> _Database_ class as core binary loader at the begining.
> The main difficulty is to respond to a SQL request, and first : being able to
> analyze it to understand what is expected.
> The SQL request analysis is a very strong job, but I suggest to ease it a lot
> by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar
> file, maybe taken from ^1^ or from elsewhere (grammars are of public domain).
> The goal of this current JIRA is only to be able to perform a
> _SELECT * FROM <shapefile layer name>_
> The WHERE clause or the selection of fields, will come later in other JIRA.
> No transactions, classic _Statement_ only.
> _PreparedStatement_ would be also implemented later (another JIRA).
> Of course, this improvment can be discarded if an open source or free driver
> is discovered, that would allow us to execute SQL requests on DBase 3 easily.
> ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe
> elsewhere they will more compliant with AntLR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
