Name collisions

[trilogysci]

While running on a large set of classes I can across a number of name issues and generation issues.

• it does not check if the class is an abstract class and will still generate new method

• it does not detect if there are static methods with the same name as instance methods and generates code with the same name for both which fails. The following code is based on the Rect class in android (see http://developer.android.com/reference/android/graphics/Rect.html) the first is the static and the second is the instance method.

  native intersects android.graphics.Rect.intersects :: Mutable s Rect -> Mutable s Rect -> ST s Bool
  native intersects :: Mutable s Rect -> Int -> Int -> Int -> Int -> ST s Bool

• it does not check if the class method name is reserved name in frege or otherwise restricted. http://developer.android.com/reference/android/widget/RelativeLayout.html contains the value TRUE which was mapped to the following.

  pure native true android.widget.RelativeLayout.TRUE :: Int

Additionally would it be possible to have a whitelist of allowable classes and exclude generating code which references classes not in the list?

[mmhelloworld]

1) I also found out this issue few days ago. For abstract classes, we shouldn't generate any constructors. 2) & 3) need to be fixed as well.

would it be possible to have a whitelist of allowable classes and exclude generating code which references classes not in the list?

This is actually a good idea. Rather than assuming the missing classes as pure, we could as well not generate any code for those that reference them.

[Ingo60]

While we are at it, ...

I noted that for pure native types the constructor gets generated as ST action. See this commit 2823f52091ccf13c4550fb16e06905f0e4098ce7 for an example.

While it is possible that we can get at a pure value only through impure actions, it will not be so in most cases. So this is not an error but just ultra-conservative.

I feel we could safely generate pure native new in many cases, unless other mutable data, exceptions etc. are involved, of course.

The follwoing rule most likely gives the correct results: When a ST phantom type s (and, of course, RealWorld) is not needed anywhere in the signature, then we can as well make it pure. Because, when the tool generates:

new :: String -> ST s Locale    -- for example     

one can always write a helper function:

purenew s = ST.run (new s)

to re-establish purity.

Honestly, if we know that some Java constructor uses global, observable mutable state, we must even make the constructor an IO action. Because ST s deals only with temporary, local (so to speak) state.

[mmhelloworld]

I feel we could safely generate pure native new in many cases, unless other mutable data, exceptions etc. are involved, of course.

Thanks Ingo! It definitely makes sense. I have created a new issue for this: https://github.com/Frege/native-gen/issues/7.

[mmhelloworld]

This issue is now partially fixed.

1. Constructors for abstract classes are now not generated
2. Frege keywords are now handled. If a Java class member results in a Frege keyword, it is now prefixed with j and suffixed with '

The only outstanding issue is to handle collision between static and instance methods (item# 2 in the original issue description).