Preparations for JSQLParser 5.0, renaming Enities #1783
Replies: 4 comments 1 reply
|
Striving for a more consistent and pleasant API, I would like to implement a simple Class scanner checking the following rules:
Since I did not find any similar Scanner/Tool on the internet, I have written a very simple prototype which finds a lot of exceptions. It can be amended on demand (better filter, more rules). I would like to clean up the API once before 5.0 and then enforce the rules (using a Unit Test). Any objections or better ideas please? Sample Output: |
|
I have flexed my Reflection Muscles and found 19 fields left, which should be probably converted into |
|
Please why exactly do we have both Do we want to clean this up for 5.0 and release a policy about Getters()/Setters()? |
|
The other question I have is: Why exactly do we allow empty Constructors leaving Objects in invalid states? E. g. something like I would not want to forcefully clean that up in the existing Grammar, but at least I would like to agree on a policy for moving forward and accepting future PRs? There are of course Constructore which can be empty, like |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I have started working on a massiv JSQLParser 5.0 re-write and got rid of a lot of redundant classes and productions. The API is much leaner and simpler now.
The remaining eye sore is about:
Select-->QueryPlainSelect--> rename toSelect(implementingQuery)SetOperationList--> rename toQuerySet(implementingQuery), we could also call itSelectSetbut that violatedVALUES(...) UNION VALUES(...)RelObjectName--> renameIdentifierSelectItem--> rename toAliasedExpression(because it has anExpressionand anAliasand is used outside of aSelect)Any objections or better ideas please?
Further I would like to suggest to remove the GitHub Wiki which is superseded by the Web Page. Contradicting information would be irritating.
All reactions