On Sat, May 8, 2010 at 9:52 PM, Mariano Martinez Peck <marianopeck@gmail.com

wrote:

On Sat, May 8, 2010 at 9:39 PM, stephane ducasse < stephane.ducasse@gmail.com> wrote:

...

On May 8, 2010, at 9:31 PM, Joachim Geidel wrote:

...

Hello everybody!

I am preparing to port JNIPort (the Smalltalk-to-Java interface) to Squeak and Pharo. However, there is a complication: Squeak and Pharo don't accept underscores in method names,

Pharo does...

Only Pharo 1.1.

Sorry. I forgot to say that I have the same problem with GLORP. For the moment, what I do for Pharo 1.0 is to load an ugly hack: (HTTPSocket httpGet: ' http://www.assembla.com/spaces/SqueakDBX/documents/dvVhPSvuCr3OqXeJe5aVNr/do...') readStream fileIn You can see that .cs if you want. Cheers Mariano

...

...

while Dolphin and VisualWorks have no problem with underscores. JNIPort contains many methods with underscores.

If you are a JNIPort user, I would like to hear what you think about the ways to solve this problem. Opinions from non-users are welcome, too, of course.

I currently see two options:

1. I can keep the versions for all platforms in sync. Obviously, I would prefer this solution, as it is less work for me. On the other hand, users of JNIPort would have to get used to new naming conventions:

- All underscores would be dropped from method names. As method names for generated methods include the type names of the arguments, this can lead to somewhat ugly looking names, as the usual camel case notation is not necessarily respected. E.g., get_int: would be replaced by getint: get_Object:String: would be replaced by getObject:String: In those simple cases, the new notation doesn't look much worse than before.

- Static fields in Java tend to have uppercase names with underscores, which I would have to drop, too: get_MAX_VALUE -> getMAXVALUE set_MAX_VALUE: -> setMAXVALUE: This has a small potential for naming conflicts if two field names in the same class differ only by underscores. But you can always use lower level methods for accessing a field if the generated method is ambiguous.

- For names of inner classes which contain a $ character, I can't replace $ by _ anymore, and would use 0 (zero) instead - it doesn't look much worse than the $ character in Java, and I can't come up with something nicer which is a legal character in a selector.

2. I could leave the VisualWorks version as it is, and maintain a second code branch for Squeak and Pharo. I don't like this solution, as it means more work for me. For JNIPort users, it would mean that their code isn't easily portable to Squeak. OTOH, it would preserve the current more-or-less nice-looking method names in generated classes.

So, what do you think?

Joachim Geidel

_______________________________________________ vwnc mailing list vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________ vwnc mailing list vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc