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