Survey: Changing method names in JNIPort?

> 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

> 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

>
>
> On Sat, May 8, 2010 at 9:39 PM, stephane ducasse <[hidden email]> 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.
>
>  
>
> > 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
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

> 1.1 soon in beta (15 of may)
>
> On May 8, 2010, at 9:52 PM, Mariano Martinez Peck wrote:
>
>>
>>
>> On Sat, May 8, 2010 at 9:39 PM, stephane ducasse <[hidden email]>
>> 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.

> 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
>