Hi Joachim,

As far as I know, Pharo now supports underscores in method names. Am I wrong?

Cheers,
Doru


On 8 May 2010, at 21:31, 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, 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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
www.tudorgirba.com

"Sometimes the best solution is not the best solution."


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to