Java Back End

[Charles]

Hops, did you know about the "extern" feature in Cobra?

Also, is the email address I have for you any good? You don't reply.

[hopscc]

Yeah - thats the thing that was renamed from 'fake' for providing/describing info of a class implemented elsewhere ( like in c# alongside cobra code) - also p/Invoke tweaking.

What are you thinking of wrt that ?

Sorry about email - The address you have is correct - unfortunately I tend to chk it at rather irregular intervals

[Charles]

Yeah - thats the thing that was renamed from 'fake' for providing/describing info of a class implemented elsewhere ( like in c# alongside cobra code) - also p/Invoke tweaking.

What are you thinking of wrt that ?

I forget if I mentioned this before, but "extern" was made exactly for specifying external signatures. I needed this for the first Cobra compiler which was written in Python (not IronPython). You can use it for the JVM work or any other back-end.

[hopscc]

Theres a new patch on the ticket.
Passes all tests and compiles itself.

[Charles]

Applied. Thanks.

-- I think when people run on -platform:jvm they are going to want the regular jvm casing for packages like "java.util".

-- We haven't discussed this before, but it seems that Cobra should see Java's getFoo and setFoo methods as properties. These were actually called properties in the context of "Java Beans" several years ago; see:

http://download.oracle.com/javase/tutorial/javabeans/properties/index.html
http://download.oracle.com/javase/tutorial/javabeans/properties/properties.html

I haven't really checked if your JVM back-end is doing that or if you commented on it.

[hopscc]

re Regular jvm package casing
Maybe so but they're not going to get it without a rework of some of the non platform dependent pieces of the compiler.

I started off doing package naming exactly for the reason cited and found it wasnt gonna work with some of the existing coding assumptions
- see Expr.cobra IdentifierExpr._bindInt with use of canBeUndottedMember to
determine whether or not to do a local symbol lookup or defer to a (later) namespace search .... or something.
(actually found this was broken when tracking the java/xjava question you asked previously).
I'm goanna go with the existing high level flow/assumptions unless its really impossible, at least until theres something more complete working

Java Properties
Yes java properties/bean properties use get/set ( and 'is') prefixes on methods - thats in JvmJarSig.cobra - JavaClassType.chkForProp
Java (libraries) doesnt use properties anything like .Net - either as commonly or even consistently named as per the above - so at best its an imperfect mapping.
I also started off doing a similar mapping for indexers but there are too many false hits for the indexer pattern (get/set method with one index arg /index arg and value) so thats been suppressed for the moment.

[hopscc]

patch3 on ticket
- set properties and some minor tweaks ('is' prefixed props NYI).

[Charles]

Thanks. Applied.

What does "NYI" mean?

[ObtuseAngle]

Not Yet Implemented, I suspect.

[Charles]

Ah thanks.

Hops, what do you mean by "'is' prefixed props"? I presume that props will be implied by methods named "getFoo" and "setFoo" allowing "print obj.foo" and "obj.foo = bar". What does any of that have to do with "is"? Maybe you already covered this in this thread or in your docs, but if so, I'm not recalling correctly.