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 > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- www.tudorgirba.com "Sometimes the best solution is not the best solution." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sat, May 8, 2010 at 9:52 PM, Mariano Martinez Peck <[hidden email]> wrote:
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/download/underscore.cs') readStream fileIn You can see that .cs if you want. Cheers Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |