Java Back End

[Charles]

Oh, is this for pairs like "isFoo()" and "setIsFoo()"?

I've been out of touch with Java for awhile and I forget what some of the commonly accepted naming conventions are.

[hopscc]

NYI as surmised = Not Yet Implemented

Java convention for properties uses get and set prefixed methods similar to .Net internal implementation with an
occasionally followed additional convention for boolean properties using accessor method prefixed with 'is'
this started from java Beans and seeped into other things.

std Property (non boolean type) foo:
accessor method getFoo() and
mutator method setFoo()

a boolean property (editable say) would use
isEditable() for the accessor and
setEditable() for the mutator

so code for checking the property reads 'better'

Code: Select all

if ( isEditable() ) {
    //do something
   setEditable(false);
  }
....
if ( ! isEditable() ) {
    ...
   setEditable(true);
 ...
}

cobra code equiv of above

pro editable = false

if .editable
    ...
    .editable  = false
...
if not .editable
    ...
    .editable = true

There was an old obscure suggestion for bool properties to use
setBoolProp for setting True and unsetBoolProp ( or resetBoolProp) to set false but noone seems to follow this

The above convention for non bool properties isnt followed particularly rigorously either as a cursory examination of java.* packages would indicate but its workable for cobra purposes...
Thats the property conventions I'm working to at the moment anyway..

Its not particularly confining for generating properties for library code since the supporting methods are always available anyway but for cobra code defined properties thats what we'll generate corresponding java code to.

[hopscc]

New patch on Java Ticket
Main changes are support for Float, Doubles and static main wrapper.
Start of cobra assertions

[Charles]

-- Thanks. Applied in changeset:2592

-- I presume that we'll support BigDecimal for "decimal" at some point in the future.

-- Why does the Java generator need to explicitly handle main() args instead of using .writeJavaParams? Maybe this next question is tied to this one:

Why does every CallExpr instance have to carry a special case flag for IdentifyMainPhase? I see it does:

mainCall = CallExpr(Token.empty, 'main', List<of Expr>(), false)
mainCall.hasMainArgs = true # backend insert args passed to main

Couldn't it do something more like:

args = [IdentifierExpr(..., 'args').bindAll to Expr]
mainCall = CallExpr(Token.empty, 'main', args, false)

-- I took out the \n in the AssertStmt C# code gen because I believe it could throw off line numbers for any warnings or errors that pass through to C#.

[hopscc]

-- Applied changeset
Cool.

-- BigDecimal
yeah probably .. eventually

-- main args and callExpr
If the args are inserted as synthesized AST Nodes ( like the rest of the setup in IdentifyMainPhase.createMainWrapper) and as per your example then every backend will generate the code conversion implicitly whether its appropriate or not re arg types and namings or alternatively the backend has to recognise a main method ( user or wrapped) and do the right thing to it in spite of what the user or wrapper may have specified.

Setting explicit attribute flags generally allows the backends to then ignore (C#) or handle specially ( java) as desired/needed for the backend.

The flag on CallExpr is because the wrapper invocation of the user supplied entry point is a callExpr and needs to use the same named Identifier as the args to the wrapped main method passed to the user version. Thats the point of .hasMainParams in Method and .hasMainArgs in CallExpr
( This is then explicit and coupled in the backend though perhaps not very obvious).

(Its a specific issue for Java cos it has a particular requirement for a specific form of a method to be recognised as a main method ).

Admittedly the main method cases aren't too different between C# and Java but they can/will be for other back ends ( e.g main method args for C/C++ or whatever ObjC does for main methods).

This is another reason for having 'cue main' explicitly up front in Cobra language since its then specially marked the backends can just handle it.
main methods are special.

More long term wrt the existing code this entire code+approach is wrong ( identifying a main candidate, synthesizing a blob of Cobra AST Nodes for a wrapper if the candidate differs from the desired form in one aspect specific to one platform).
The flagging I added for Java isnt sufficient for other platform/backends I can think of and would require more specific tweaking for different main method forms .

What it should do is identify the candidate method and flag it ( or have it implicitly flagged by the language ('cue main') and pass the entire handling/wrapping/arg synthesis off to the backend implementation to generate in one hit (simply, clearly and in one place).
Main method forms and restrictions are backend specific after all..

-- \n removal
Hmm - I'd feel better about that if you could actually point to an example of (Test or other ) failure

Examining the (C#) code gen shows the (new) line has the same line number marker as the condition check which is the same line number as the previous aggregated condition so I believe your belief is unfounded ( ).

[Charles]

-- Re: "cue main" I'll give it more thought.

-- Re: \n in C# code generation, you are correct. I had forgotten that I had implemented the #line directives at a lower level that looks for the newline (CurlyWriter). I have added it back in.

[hopscc]

Theres a new patch on the ticket for pushing down and making explicit mainWrapper code emission and simplifying upper code as
mentioned previously.
Some more checks on main method validity and tests for same.

[hopscc]

Hy chuck
- looks like in the last two patches applied for the java support you missed adding some new java files from the patch into the tree in
Source/Cobra.Lang/Java
(changesets 2587 and 2592)

patch3 added Delegate.java ( and modded it in patch 4)
patch4 added CobraDirectString.java

pulling a new tree doesnt provide them.

A quick smoke test on the java part of the tree post patch application would be to run
Source/Cobra.Lang/Java/mkjarAll which should complain about any explicitly listed missing files.

[Charles]

-- I added the two files and set the execute bit on the mkjarAll.

-- Oddly, I don't see your activity for adding the patch in the Timeline, http://cobra-language.com/trac/cobra/timeline, although the patch is there. Do you see it in the Timeline? I've been relying on this to tell when there is activity, so this is annoying.

-- Patch applied. Thanks.

[hopscc]

Nah - I noticed it didnt show up after I added the patch last night.
Figured it was some change in the trac config /version upgrade(?) from the server upgrade/reinstall.

The previous version also had an extra item in the (timeline) rhs selection box - something like 'changed tickets' - looks like its dropped out
for some reason - perhaps the two are related