Allow more interoperability between type Rexx and type String (was NETREXX-124)

[rvjansen]

Java String and Rexx are sufficiently similar in usage that it might be a good idea to allow the methods of one to be called on the other . MFC indicated this thought was already entertained during the inception of NetRexx. Several new users have indicated their surprise over the necessity to cast or construct.

[rvjansen]

Comment by Kermit Kiser [ 26/May/15 ] This seems like a great idea. The question that needs to be answered first is "how will namespace conflicts be handled?". What if there is a method with the same signature in both String and Rexx class?

[rvjansen]

Comment by Thomas.Schneider .Wien [ 05/Jun/15 ]

May I suggest to simply add a new type (class) Text which extends Rexx and String and shares any&all T ext related functions ? Similiar, for Numerics ... ... add a class Numeric ... This then would allow to use MFC's BigDecimal algorithm's instead of the ancient Rexx ones when wanted by option -BigDecimal Thomas Schneider

[rvjansen]

Comment by rvjansen [ 04/Jun/15 ] I would suggest to use the options binary status to give preference to method selection in case of name clashes. When binary is the the active status, we would prefer the JVM methods (as strings that have not been typed to Rexx will be java Strings); when we are in nobinary the Rexx methods should be preferred - only when there are clashes. We probably need to design some test cases and have an inventory so we know what to expect. Also, thinking forward to JS and C# versions, this should work for their native string types.

[rvjansen]

Comment by Thomas.Schneider .Wien [ 05/Jun/15 ] In any case the methods of class Rexx and String should work for both cases (options binary and nobinary) I think. Many users start without option binary , and later introduce option binary for tu ning. I also think that a type Text would be more readable than Rexx for a novice. But I don't want to initiate a philisophical fight Thomas.

[rvjansen]

Comment by Kermit Kiser [ 07/Jun/15 ] Since we are trying to eliminate the dif ferences between Rexx and String to reduce confusion for Java programmers, adding more classes would go in the opposite direction. In any case after research, here is the current state of namespace/headspace collisions with comments: method charAt(index=int) returns char identical method compareTo(i2=Object) returns int Signals ClassCastException similar probably ok (Comparable interface implementations) method concat(set=RexxSet, rhs=Rexx, blanks=int) private returns Rexx dif f sig undocumented, can handle by convert to strings method equals(rhs=Object) returns boolean similar convert to more powerful Rexx compare? method format(before=Rexx null, after=Rexx null,- str vs num no idea how to resolve! possibly uncommon enough to ignore? method hashCode returns int similar probably ok asis method isEmpty() returns boolean zing! string=(is length=0?), rexx=has indexed values? (Map interface) possibly move to RxMap so Map cast uses indexes but direct uses string method? method length() returns Rexx; return intlength() similar method toCharArray() returns char[] identical method toString() returns String identical Clearly Mike made an ef fort to follow th e String pattern. I wonder when format was added to String. If we can resolve the format and isEmpty issues we can proceed with this feature. Also we need to consider what to do if someone attempts to add an indexed value to a String