Proposed constructor

[ThSITC]

May, *I*, please again *gagain* ***propose*** to:

use *other* Types (classes, in the NetRexx&Java  Sense) *available*:

For Instance:

WordList -- a List of Blank separated Words
CommaList -- a List of (Comma(Blank) separated *Members*)

Any, and all, Methods available for *Java Strings*, and Rexx &/ NetRexx,
shall be then available
By the NetRexx Compiler/Preprocessor *by default*

Thus:

x = Rexx
y = x.endswith('(CR)')

shall be *simply supported*, by *our commonly designed&supported* ***
so called HUMAN Language  :-)

Ok, so far, can you *please* still follow my ideas?

Massa Thomas (aka: Crazy Uncle Tom)
===========================================================================

Am 24.11.2012 05:47, schrieb Bill Fenlason:

> Kermit,
>
> Please do not misunderstand my objection - I am all in favor of
> convenient interoperability with the Java Collections.  What I object
> to is the expansion of the Rexx constructor to go from a string to a
> collection of strings (i.e an indexed string array).
>
> As you know, internally Rexx objects use a Java Hashmap, the
> undocumented "keys" method returns a Java Enumeration, and so on.
>
> But from a language perspective, the equivalent of "new Rexx('abc')"
> which implies a single Rexx string and your new constructors are apt
> to be confusing.
>
> I think user methods could be used to add indexed string instances to
> a Rexx object, or perhaps a Rexx object method (possibly based on your
> constructors) could be added.  I also think NetRexx should provide the
> equivalent of iterators for the keys and values of an indexed string
> or other methods for the retrieval of data (size, keys, values) from it.
>
> I'm not in favor of using Java Collection objects explicitly as
> NetRexx arguments.  The Collections are not inherent in the Java
> Language (the for-each loop uses anything that is iterable), and I
> don't believe that there should be any explicit use of the Java
> Collections in NetRexx either.  If anything, an iterable argument
> should be used.
>
> Bill
>
> On 11/22/2012 3:13 PM, Kermit Kiser wrote:
>> Thank you to all who participated in this discussion. When I started
>> it I was just trying to see if there was any interest in enhanced
>> support for interfacing NetRexx with Java data structures like arrays
>> and collections. I did not intend to start a language philosophy war.
>> Since the responses appear more negative than positive, it seems
>> unlikely to me that we will see better support for the advanced data
>> items in an official release of NetRexx any time soon. That does
>> leave me with a bit of a feeling of impending doom for NetRexx since
>> I feel that without better support for modern Java, NetRexx will die.
>>
>> On the other hand, the many comments caused me to re-evaluate and
>> revise the sample code from my proposal to handle the technical
>> objections to the idea. Obviously I cannot address the philosophical
>> objections. But in case there is anyone interested in testing the
>> proposed advanced Java support, I have added the revised code to the
>> experimental branch of NetRexx. The updated source and binaries are
>> available at the usual location:
>>
>> http://kenai.com/projects/netrexx-plus/downloads/directory/Experimental%20NetRexx%20Build 
>>
>>
>> The normal warnings about experimental code not being stable or a
>> guaranteed API apply here. (That said, I will be testing the code in
>> my commercial Android applications.) The new code was actually added
>> in two locations: a constructor in class Rexx and a factory in class
>> RexxUtil. This allows both approaches to be tested at the same time
>> and provides two options in case future sentiment shifts towards
>> adding more advanced Java support to an official release of NetRexx.
>> Usage is as follows:
>>
>>         Rexx(keys, values, default)
>>         RexxUtil.getRexx(keys, values, default)
>>
>> where keys and values are any arrays or Java collections framework
>> Lists and default is an optional object to provide a default value
>> for the Rexx variable. All elements are converted to strings before
>> being added to the indexed Rexx variable which is returned. Null can
>> be passed for one of the keys or values parameters to default to a
>> 1-n integer sequence matching the other parameter but if both
>> parameters are provided they must have the same length. Note that
>> arrays do not need to be string arrays and that primitive arrays such
>> as int[] are also accepted.
>>
>> The cost of adding the two copies of the code to the NetRexx runtime
>> module was a 1439 byte increase in size. The experimental
>> NetRexxR.jar with full collections support is now 45,061 bytes. The
>> new code is not optimized for size or speed yet and may need added
>> safety checks for duplicate keys, etc.
>>
>> Please let me know if you test this and find errors or something that
>> needs changes or if you want to see my test programs.
>>
>> Thanks all,
>> -- Kermit
>>
>>
>> On 11/21/2012 3:20 PM, Bill Fenlason wrote:
>>> I've read all the appends in this discussion, and I'm not convinced
>>> that attempting to coerce the Java Collections framework into the
>>> Rexx() class is a good idea.
>>>
>>> With regard to the Rexx constructors, I note that in the Rexx
>>> Language manual (version 3.01 August 23, 2012) on page 183 "The Rexx
>>> Class", for each constructor, the definition begins "Constructs a
>>> STRING ..." (emphasis added).  There can be little doubt that a Rexx
>>> instance is a string, and not an indexed string (which is equivalent
>>> to an array of strings).
>>>
>>> Adding one or more constructors to the Rexx class which construct an
>>> array of strings (indexed string) is fundamentally a bad idea (imho).
>>>
>>> Providing methods which set a Rexx array (indexed string) as desired
>>> might be a better approach.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Kermit,

while you are at it, could you have a look at why line 47 in netrexx/netrexxc/test/CollectionSupport.nrx still fails? I have it commented out, but if I uncomment, it yields:

1) testTreeSet(CollectionSupport)java.lang.ClassCastException: netrexx.lang.Rexx cannot be cast to java.lang.String
        at java.lang.String.compareTo(String.java:92)
        at java.util.TreeMap.put(TreeMap.java:545)
        at java.util.TreeSet.add(TreeSet.java:238)
        at CollectionSupport.testTreeSet(CollectionSupport.java:47)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at zAllTests.main(zAllTests.java:33)

FAILURES!!!
Tests run: 17,  Failures: 0,  Errors: 1

many thanks in advance,

best regards,

René.
 
On 24 nov. 2012, at 13:09, Kermit Kiser <[hidden email]> wrote:

> Bill --
>
> Your BIF idea is brilliant! I have refactored the test code to add it. That gives us a third option to test (built-in method) along with the constructor and factory approaches. In addition it shrinks the module size since the actual utility code (1185 bytes) is in only one spot and adds a new feature: merged maps. It might even solve some of the philosophical objections since it does not require a new constructor. To build a new indexed Rexx map with the new method you can now do this:
>
> Rexx(default).buildMap(keys, values)
>
> where keys and values are any arrays or Java collections framework Lists and default is the default value for the Rexx variable (using the standard Rexx constructors).
>
> The factory approach bothered me for a couple of reasons: In this case it is simply another constructor for a Rexx object hidden in another class and the other class (RexxUtil or whatever is chosen) would have to be added to the NetRexx documentation.
>
> An indexed Rexx variable actually contains a Java Hashtable. When Java added the collections framework, the Hashtable was refactored to be a collections framework Map which means that an indexed Rexx object is basically a Java Map but is missing the formal methods defined in the interface. The collections support that René has been testing was added to the experimental branch of NetRexx over a year ago to provide the missing interface methods and classes. (I also looked extensively at converting the Rexx class to use the faster Hashmap but could not figure out how to do that because of the way the Rexx class uses "ghost" nodes. That does not mean that it could not be done somehow.)
>
> All of the new iterators and methods you suggested are already included in the collections support in the experimental NetRexx branch as part of the Java Map interface.
>
> Your last comment does not make sense to me. The Iterable interface means that something has an Iterator which is also an interface in the Java collections framework. The List interface which I chose is a sub-interface of Iterable which means something that has an ordered Iterator (it doesn't make any sense to create a map from non-ordered sets). All of these interfaces are part of the Java collections framework. Interfaces are not objects - they just define a standardized behavior for objects. I hope that makes things clearer.
>
> -- Kermit
>
> On 11/23/2012 6:47 PM, Bill Fenlason wrote:
>> Kermit,
>>
>> Please do not misunderstand my objection - I am all in favor of convenient interoperability with the Java Collections.  What I object to is the expansion of the Rexx constructor to go from a string to a collection of strings (i.e an indexed string array).
>>
>> As you know, internally Rexx objects use a Java Hashmap, the undocumented "keys" method returns a Java Enumeration, and so on.
>>
>> But from a language perspective, the equivalent of "new Rexx('abc')" which implies a single Rexx string and your new constructors are apt to be confusing.
>>
>> I think user methods could be used to add indexed string instances to a Rexx object, or perhaps a Rexx object method (possibly based on your constructors) could be added.  I also think NetRexx should provide the equivalent of iterators for the keys and values of an indexed string or other methods for the retrieval of data (size, keys, values) from it.
>>
>> I'm not in favor of using Java Collection objects explicitly as NetRexx arguments.  The Collections are not inherent in the Java Language (the for-each loop uses anything that is iterable), and I don't believe that there should be any explicit use of the Java Collections in NetRexx either.  If anything, an iterable argument should be used.
>>
>> Bill
>>
>> On 11/22/2012 3:13 PM, Kermit Kiser wrote:
>>> Thank you to all who participated in this discussion. When I started it I was just trying to see if there was any interest in enhanced support for interfacing NetRexx with Java data structures like arrays and collections. I did not intend to start a language philosophy war. Since the responses appear more negative than positive, it seems unlikely to me that we will see better support for the advanced data items in an official release of NetRexx any time soon. That does leave me with a bit of a feeling of impending doom for NetRexx since I feel that without better support for modern Java, NetRexx will die.
>>>
>>> On the other hand, the many comments caused me to re-evaluate and revise the sample code from my proposal to handle the technical objections to the idea. Obviously I cannot address the philosophical objections. But in case there is anyone interested in testing the proposed advanced Java support, I have added the revised code to the experimental branch of NetRexx. The updated source and binaries are available at the usual location:
>>>
>>> http://kenai.com/projects/netrexx-plus/downloads/directory/Experimental%20NetRexx%20Build 
>>>
>>> The normal warnings about experimental code not being stable or a guaranteed API apply here. (That said, I will be testing the code in my commercial Android applications.) The new code was actually added in two locations: a constructor in class Rexx and a factory in class RexxUtil. This allows both approaches to be tested at the same time and provides two options in case future sentiment shifts towards adding more advanced Java support to an official release of NetRexx. Usage is as follows:
>>>
>>>        Rexx(keys, values, default)
>>>        RexxUtil.getRexx(keys, values, default)
>>>
>>> where keys and values are any arrays or Java collections framework Lists and default is an optional object to provide a default value for the Rexx variable. All elements are converted to strings before being added to the indexed Rexx variable which is returned. Null can be passed for one of the keys or values parameters to default to a 1-n integer sequence matching the other parameter but if both parameters are provided they must have the same length. Note that arrays do not need to be string arrays and that primitive arrays such as int[] are also accepted.
>>>
>>> The cost of adding the two copies of the code to the NetRexx runtime module was a 1439 byte increase in size. The experimental NetRexxR.jar with full collections support is now 45,061 bytes. The new code is not optimized for size or speed yet and may need added safety checks for duplicate keys, etc.
>>>
>>> Please let me know if you test this and find errors or something that needs changes or if you want to see my test programs.
>>>
>>> Thanks all,
>>> -- Kermit
>>>
>>>
>>> On 11/21/2012 3:20 PM, Bill Fenlason wrote:
>>>> I've read all the appends in this discussion, and I'm not convinced that attempting to coerce the Java Collections framework into the Rexx() class is a good idea.
>>>>
>>>> With regard to the Rexx constructors, I note that in the Rexx Language manual (version 3.01 August 23, 2012) on page 183 "The Rexx Class", for each constructor, the definition begins "Constructs a STRING ..." (emphasis added).  There can be little doubt that a Rexx instance is a string, and not an indexed string (which is equivalent to an array of strings).
>>>>
>>>> Adding one or more constructors to the Rexx class which construct an array of strings (indexed string) is fundamentally a bad idea (imho).
>>>>
>>>> Providing methods which set a Rexx array (indexed string) as desired might be a better approach.
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

René --

You may find this amusing - I am actually working on my commercial
Android applications which led to my needing to update our Android IDE
support to handle Android library projects so that projects in NetRexx
could access them which led to adding the ability to create Android
library projects in NetRexx code as well as standard application
projects which will lead to updating the new jEdit plugin which contains
the current Android IDE. This whole process exposed the need for better
NetRexx support for accessing multi-value Java data structures like
arrays and collections which led to the recent discussion on the mailing
list and the related experimental enhancements and the conversion
problem in the interpreter which I reported. It also exposed some flaws
in the Android build.xml process for which I need to file a bug report
at Google. In addition I discovered that Ant really sucks at doing
complex build tasks like we need for the library project support because
it has no concept of variables or counters or iterative processes - but
it does have a JSR223 scripting interface which means that I need to
dust off the prototype NetRexx JSR223 code and complete it now.

Sorry for the sidetrack - I think I am a bit loopy from lack of sleep!

Anyway, you may recall that we looked at the treeset problem last year
and found that you cannot mix Java Strings and Rexx strings in ordered
sets unless you provide your own comparator because Java does not know
how to compare Strings and Rexx objects even though NetRexx does. I have
now added your RexxComparator to package netrexx.lang in the after3.01
experimental branch since it seems to me like a valid component of the
NetRexx collections support update. (It adds about 600 bytes to the size
but the whole update is about 10k so not really much difference.)

With this addition, you can fix the CollectionSupport.nrx program by
changing your TreeSet definition to:

u = TreeSet(RexxComparator())

Of course even without it you could fix it by forcing line 47 to add the
string as a Rexx object like this:

u.add(Rexx 'aap') -- still fails: funny because casting Rexx to String
should be easy

Does that make sense?

-- Kermit

On 11/24/2012 8:19 AM, René Jansen wrote:

> Kermit,
>
> while you are at it, could you have a look at why line 47 in netrexx/netrexxc/test/CollectionSupport.nrx still fails? I have it commented out, but if I uncomment, it yields:
>
> 1) testTreeSet(CollectionSupport)java.lang.ClassCastException: netrexx.lang.Rexx cannot be cast to java.lang.String
> at java.lang.String.compareTo(String.java:92)
> at java.util.TreeMap.put(TreeMap.java:545)
> at java.util.TreeSet.add(TreeSet.java:238)
> at CollectionSupport.testTreeSet(CollectionSupport.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at zAllTests.main(zAllTests.java:33)
>
> FAILURES!!!
> Tests run: 17,  Failures: 0,  Errors: 1
>
> many thanks in advance,
>
> best regards,
>
> René.
>  
> On 24 nov. 2012, at 13:09, Kermit Kiser <[hidden email]> wrote:
>
>> Bill --
>>
>> Your BIF idea is brilliant! I have refactored the test code to add it. That gives us a third option to test (built-in method) along with the constructor and factory approaches. In addition it shrinks the module size since the actual utility code (1185 bytes) is in only one spot and adds a new feature: merged maps. It might even solve some of the philosophical objections since it does not require a new constructor. To build a new indexed Rexx map with the new method you can now do this:
>>
>> Rexx(default).buildMap(keys, values)
>>
>> where keys and values are any arrays or Java collections framework Lists and default is the default value for the Rexx variable (using the standard Rexx constructors).
>>
>> The factory approach bothered me for a couple of reasons: In this case it is simply another constructor for a Rexx object hidden in another class and the other class (RexxUtil or whatever is chosen) would have to be added to the NetRexx documentation.
>>
>> An indexed Rexx variable actually contains a Java Hashtable. When Java added the collections framework, the Hashtable was refactored to be a collections framework Map which means that an indexed Rexx object is basically a Java Map but is missing the formal methods defined in the interface. The collections support that René has been testing was added to the experimental branch of NetRexx over a year ago to provide the missing interface methods and classes. (I also looked extensively at converting the Rexx class to use the faster Hashmap but could not figure out how to do that because of the way the Rexx class uses "ghost" nodes. That does not mean that it could not be done somehow.)
>>
>> All of the new iterators and methods you suggested are already included in the collections support in the experimental NetRexx branch as part of the Java Map interface.
>>
>> Your last comment does not make sense to me. The Iterable interface means that something has an Iterator which is also an interface in the Java collections framework. The List interface which I chose is a sub-interface of Iterable which means something that has an ordered Iterator (it doesn't make any sense to create a map from non-ordered sets). All of these interfaces are part of the Java collections framework. Interfaces are not objects - they just define a standardized behavior for objects. I hope that makes things clearer.
>>
>> -- Kermit
>>
>> On 11/23/2012 6:47 PM, Bill Fenlason wrote:
>>> Kermit,
>>>
>>> Please do not misunderstand my objection - I am all in favor of convenient interoperability with the Java Collections.  What I object to is the expansion of the Rexx constructor to go from a string to a collection of strings (i.e an indexed string array).
>>>
>>> As you know, internally Rexx objects use a Java Hashmap, the undocumented "keys" method returns a Java Enumeration, and so on.
>>>
>>> But from a language perspective, the equivalent of "new Rexx('abc')" which implies a single Rexx string and your new constructors are apt to be confusing.
>>>
>>> I think user methods could be used to add indexed string instances to a Rexx object, or perhaps a Rexx object method (possibly based on your constructors) could be added.  I also think NetRexx should provide the equivalent of iterators for the keys and values of an indexed string or other methods for the retrieval of data (size, keys, values) from it.
>>>
>>> I'm not in favor of using Java Collection objects explicitly as NetRexx arguments.  The Collections are not inherent in the Java Language (the for-each loop uses anything that is iterable), and I don't believe that there should be any explicit use of the Java Collections in NetRexx either.  If anything, an iterable argument should be used.
>>>
>>> Bill
>>>
>>> On 11/22/2012 3:13 PM, Kermit Kiser wrote:
>>>> Thank you to all who participated in this discussion. When I started it I was just trying to see if there was any interest in enhanced support for interfacing NetRexx with Java data structures like arrays and collections. I did not intend to start a language philosophy war. Since the responses appear more negative than positive, it seems unlikely to me that we will see better support for the advanced data items in an official release of NetRexx any time soon. That does leave me with a bit of a feeling of impending doom for NetRexx since I feel that without better support for modern Java, NetRexx will die.
>>>>
>>>> On the other hand, the many comments caused me to re-evaluate and revise the sample code from my proposal to handle the technical objections to the idea. Obviously I cannot address the philosophical objections. But in case there is anyone interested in testing the proposed advanced Java support, I have added the revised code to the experimental branch of NetRexx. The updated source and binaries are available at the usual location:
>>>>
>>>> http://kenai.com/projects/netrexx-plus/downloads/directory/Experimental%20NetRexx%20Build
>>>>
>>>> The normal warnings about experimental code not being stable or a guaranteed API apply here. (That said, I will be testing the code in my commercial Android applications.) The new code was actually added in two locations: a constructor in class Rexx and a factory in class RexxUtil. This allows both approaches to be tested at the same time and provides two options in case future sentiment shifts towards adding more advanced Java support to an official release of NetRexx. Usage is as follows:
>>>>
>>>>         Rexx(keys, values, default)
>>>>         RexxUtil.getRexx(keys, values, default)
>>>>
>>>> where keys and values are any arrays or Java collections framework Lists and default is an optional object to provide a default value for the Rexx variable. All elements are converted to strings before being added to the indexed Rexx variable which is returned. Null can be passed for one of the keys or values parameters to default to a 1-n integer sequence matching the other parameter but if both parameters are provided they must have the same length. Note that arrays do not need to be string arrays and that primitive arrays such as int[] are also accepted.
>>>>
>>>> The cost of adding the two copies of the code to the NetRexx runtime module was a 1439 byte increase in size. The experimental NetRexxR.jar with full collections support is now 45,061 bytes. The new code is not optimized for size or speed yet and may need added safety checks for duplicate keys, etc.
>>>>
>>>> Please let me know if you test this and find errors or something that needs changes or if you want to see my test programs.
>>>>
>>>> Thanks all,
>>>> -- Kermit
>>>>
>>>>
>>>> On 11/21/2012 3:20 PM, Bill Fenlason wrote:
>>>>> I've read all the appends in this discussion, and I'm not convinced that attempting to coerce the Java Collections framework into the Rexx() class is a good idea.
>>>>>
>>>>> With regard to the Rexx constructors, I note that in the Rexx Language manual (version 3.01 August 23, 2012) on page 183 "The Rexx Class", for each constructor, the definition begins "Constructs a STRING ..." (emphasis added).  There can be little doubt that a Rexx instance is a string, and not an indexed string (which is equivalent to an array of strings).
>>>>>
>>>>> Adding one or more constructors to the Rexx class which construct an array of strings (indexed string) is fundamentally a bad idea (imho).
>>>>>
>>>>> Providing methods which set a Rexx array (indexed string) as desired might be a better approach.
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>>
>>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Kermit, & all,

The problem, as I can recall, did come from >*the Fact* (Hostorically,
as we all do  *know*, hopwefully,
*by now*, *that the STRING Class* has been defines as *FINALLY* :-(

No *matter*, for me; (personal opinion, of course), wher a *Text*
is reperesnted as a STring, Rexx, *or* Char Sequence*

*A* *Text* is a *Text * is a *Text*  (Tautology again, you might RECALL ;-))
A *Number* is a *Number* is a *Number*
A *Positive Number* is a *Positive Number+ +++IS not+++
....  A   *Negative Number*

Hence, why (the Hell) cannot we *concentrate* *on HUMAN Concepts*, here,
instead of
*archaic* ideas and Thoughts???

Times are saying: Times are changing ...
Thomas.
=====================================================================================
Am 25.11.2012 02:33, schrieb Kermit Kiser:

> René --
>
> You may find this amusing - I am actually working on my commercial
> Android applications which led to my needing to update our Android IDE
> support to handle Android library projects so that projects in NetRexx
> could access them which led to adding the ability to create Android
> library projects in NetRexx code as well as standard application
> projects which will lead to updating the new jEdit plugin which
> contains the current Android IDE. This whole process exposed the need
> for better NetRexx support for accessing multi-value Java data
> structures like arrays and collections which led to the recent
> discussion on the mailing list and the related experimental
> enhancements and the conversion problem in the interpreter which I
> reported. It also exposed some flaws in the Android build.xml process
> for which I need to file a bug report at Google. In addition I
> discovered that Ant really sucks at doing complex build tasks like we
> need for the library project support because it has no concept of
> variables or counters or iterative processes - but it does have a
> JSR223 scripting interface which means that I need to dust off the
> prototype NetRexx JSR223 code and complete it now.
>
> Sorry for the sidetrack - I think I am a bit loopy from lack of sleep!
>
> Anyway, you may recall that we looked at the treeset problem last year
> and found that you cannot mix Java Strings and Rexx strings in ordered
> sets unless you provide your own comparator because Java does not know
> how to compare Strings and Rexx objects even though NetRexx does. I
> have now added your RexxComparator to package netrexx.lang in the
> after3.01 experimental branch since it seems to me like a valid
> component of the NetRexx collections support update. (It adds about
> 600 bytes to the size but the whole update is about 10k so not really
> much difference.)
>
> With this addition, you can fix the CollectionSupport.nrx program by
> changing your TreeSet definition to:
>
> u = TreeSet(RexxComparator())
>
> Of course even without it you could fix it by forcing line 47 to add
> the string as a Rexx object like this:
>
> u.add(Rexx 'aap') -- still fails: funny because casting Rexx to String
> should be easy
>
> Does that make sense?
>
> -- Kermit
>
> On 11/24/2012 8:19 AM, René Jansen wrote:
>> Kermit,
>>
>> while you are at it, could you have a look at why line 47 in
>> netrexx/netrexxc/test/CollectionSupport.nrx still fails? I have it
>> commented out, but if I uncomment, it yields:
>>
>> 1) testTreeSet(CollectionSupport)java.lang.ClassCastException:
>> netrexx.lang.Rexx cannot be cast to java.lang.String
>>     at java.lang.String.compareTo(String.java:92)
>>     at java.util.TreeMap.put(TreeMap.java:545)
>>     at java.util.TreeSet.add(TreeSet.java:238)
>>     at CollectionSupport.testTreeSet(CollectionSupport.java:47)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>     at zAllTests.main(zAllTests.java:33)
>>
>> FAILURES!!!
>> Tests run: 17,  Failures: 0,  Errors: 1
>>
>> many thanks in advance,
>>
>> best regards,
>>
>> René.
>>   On 24 nov. 2012, at 13:09, Kermit Kiser <[hidden email]>
>> wrote:
>>
>>> Bill --
>>>
>>> Your BIF idea is brilliant! I have refactored the test code to add
>>> it. That gives us a third option to test (built-in method) along
>>> with the constructor and factory approaches. In addition it shrinks
>>> the module size since the actual utility code (1185 bytes) is in
>>> only one spot and adds a new feature: merged maps. It might even
>>> solve some of the philosophical objections since it does not require
>>> a new constructor. To build a new indexed Rexx map with the new
>>> method you can now do this:
>>>
>>> Rexx(default).buildMap(keys, values)
>>>
>>> where keys and values are any arrays or Java collections framework
>>> Lists and default is the default value for the Rexx variable (using
>>> the standard Rexx constructors).
>>>
>>> The factory approach bothered me for a couple of reasons: In this
>>> case it is simply another constructor for a Rexx object hidden in
>>> another class and the other class (RexxUtil or whatever is chosen)
>>> would have to be added to the NetRexx documentation.
>>>
>>> An indexed Rexx variable actually contains a Java Hashtable. When
>>> Java added the collections framework, the Hashtable was refactored
>>> to be a collections framework Map which means that an indexed Rexx
>>> object is basically a Java Map but is missing the formal methods
>>> defined in the interface. The collections support that René has been
>>> testing was added to the experimental branch of NetRexx over a year
>>> ago to provide the missing interface methods and classes. (I also
>>> looked extensively at converting the Rexx class to use the faster
>>> Hashmap but could not figure out how to do that because of the way
>>> the Rexx class uses "ghost" nodes. That does not mean that it could
>>> not be done somehow.)
>>>
>>> All of the new iterators and methods you suggested are already
>>> included in the collections support in the experimental NetRexx
>>> branch as part of the Java Map interface.
>>>
>>> Your last comment does not make sense to me. The Iterable interface
>>> means that something has an Iterator which is also an interface in
>>> the Java collections framework. The List interface which I chose is
>>> a sub-interface of Iterable which means something that has an
>>> ordered Iterator (it doesn't make any sense to create a map from
>>> non-ordered sets). All of these interfaces are part of the Java
>>> collections framework. Interfaces are not objects - they just define
>>> a standardized behavior for objects. I hope that makes things clearer.
>>>
>>> -- Kermit
>>>
>>> On 11/23/2012 6:47 PM, Bill Fenlason wrote:
>>>> Kermit,
>>>>
>>>> Please do not misunderstand my objection - I am all in favor of
>>>> convenient interoperability with the Java Collections. What I
>>>> object to is the expansion of the Rexx constructor to go from a
>>>> string to a collection of strings (i.e an indexed string array).
>>>>
>>>> As you know, internally Rexx objects use a Java Hashmap, the
>>>> undocumented "keys" method returns a Java Enumeration, and so on.
>>>>
>>>> But from a language perspective, the equivalent of "new
>>>> Rexx('abc')" which implies a single Rexx string and your new
>>>> constructors are apt to be confusing.
>>>>
>>>> I think user methods could be used to add indexed string instances
>>>> to a Rexx object, or perhaps a Rexx object method (possibly based
>>>> on your constructors) could be added.  I also think NetRexx should
>>>> provide the equivalent of iterators for the keys and values of an
>>>> indexed string or other methods for the retrieval of data (size,
>>>> keys, values) from it.
>>>>
>>>> I'm not in favor of using Java Collection objects explicitly as
>>>> NetRexx arguments.  The Collections are not inherent in the Java
>>>> Language (the for-each loop uses anything that is iterable), and I
>>>> don't believe that there should be any explicit use of the Java
>>>> Collections in NetRexx either.  If anything, an iterable argument
>>>> should be used.
>>>>
>>>> Bill
>>>>
>>>> On 11/22/2012 3:13 PM, Kermit Kiser wrote:
>>>>> Thank you to all who participated in this discussion. When I
>>>>> started it I was just trying to see if there was any interest in
>>>>> enhanced support for interfacing NetRexx with Java data structures
>>>>> like arrays and collections. I did not intend to start a language
>>>>> philosophy war. Since the responses appear more negative than
>>>>> positive, it seems unlikely to me that we will see better support
>>>>> for the advanced data items in an official release of NetRexx any
>>>>> time soon. That does leave me with a bit of a feeling of impending
>>>>> doom for NetRexx since I feel that without better support for
>>>>> modern Java, NetRexx will die.
>>>>>
>>>>> On the other hand, the many comments caused me to re-evaluate and
>>>>> revise the sample code from my proposal to handle the technical
>>>>> objections to the idea. Obviously I cannot address the
>>>>> philosophical objections. But in case there is anyone interested
>>>>> in testing the proposed advanced Java support, I have added the
>>>>> revised code to the experimental branch of NetRexx. The updated
>>>>> source and binaries are available at the usual location:
>>>>>
>>>>> http://kenai.com/projects/netrexx-plus/downloads/directory/Experimental%20NetRexx%20Build 
>>>>>
>>>>>
>>>>> The normal warnings about experimental code not being stable or a
>>>>> guaranteed API apply here. (That said, I will be testing the code
>>>>> in my commercial Android applications.) The new code was actually
>>>>> added in two locations: a constructor in class Rexx and a factory
>>>>> in class RexxUtil. This allows both approaches to be tested at the
>>>>> same time and provides two options in case future sentiment shifts
>>>>> towards adding more advanced Java support to an official release
>>>>> of NetRexx. Usage is as follows:
>>>>>
>>>>>         Rexx(keys, values, default)
>>>>>         RexxUtil.getRexx(keys, values, default)
>>>>>
>>>>> where keys and values are any arrays or Java collections framework
>>>>> Lists and default is an optional object to provide a default value
>>>>> for the Rexx variable. All elements are converted to strings
>>>>> before being added to the indexed Rexx variable which is returned.
>>>>> Null can be passed for one of the keys or values parameters to
>>>>> default to a 1-n integer sequence matching the other parameter but
>>>>> if both parameters are provided they must have the same length.
>>>>> Note that arrays do not need to be string arrays and that
>>>>> primitive arrays such as int[] are also accepted.
>>>>>
>>>>> The cost of adding the two copies of the code to the NetRexx
>>>>> runtime module was a 1439 byte increase in size. The experimental
>>>>> NetRexxR.jar with full collections support is now 45,061 bytes.
>>>>> The new code is not optimized for size or speed yet and may need
>>>>> added safety checks for duplicate keys, etc.
>>>>>
>>>>> Please let me know if you test this and find errors or something
>>>>> that needs changes or if you want to see my test programs.
>>>>>
>>>>> Thanks all,
>>>>> -- Kermit
>>>>>
>>>>>
>>>>> On 11/21/2012 3:20 PM, Bill Fenlason wrote:
>>>>>> I've read all the appends in this discussion, and I'm not
>>>>>> convinced that attempting to coerce the Java Collections
>>>>>> framework into the Rexx() class is a good idea.
>>>>>>
>>>>>> With regard to the Rexx constructors, I note that in the Rexx
>>>>>> Language manual (version 3.01 August 23, 2012) on page 183 "The
>>>>>> Rexx Class", for each constructor, the definition begins
>>>>>> "Constructs a STRING ..." (emphasis added).  There can be little
>>>>>> doubt that a Rexx instance is a string, and not an indexed string
>>>>>> (which is equivalent to an array of strings).
>>>>>>
>>>>>> Adding one or more constructors to the Rexx class which construct
>>>>>> an array of strings (indexed string) is fundamentally a bad idea
>>>>>> (imho).
>>>>>>
>>>>>> Providing methods which set a Rexx array (indexed string) as
>>>>>> desired might be a better approach.
>>>> _______________________________________________
>>>> Ibm-netrexx mailing list
>>>> [hidden email]
>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 Hi Kermit,

> Sorry it takes me a while to respond sometimes due to other projects.

Same here ... :-)

 

> >>       method Rexx(m=Map)
> >>       method Rexx(r=Rexx,s=Rexx)
> > I'm not familiar with Java Maps or what the second of these
> > would do.  
> > Can you point me to the documentation for these constructors?
> The Java Map is an interface defined as part of the Java
> collections framework. Here is a document for it:
> http://docs.oracle.com/javase/6/docs/api/java/util/Map.html
>
> Map is basically the Java version of a Rexx indexed variable.
> In fact the HashTable that NetRexx uses to provide
> key==>value mappings was later changed in Java to support the
> Map interface which means that a Rexx indexed variable was
> already a Java Map under the covers -- it just needed the
> methods from the interface to be added to become a full Java
> collection type.

Interesting -- thanks.

> Although an interface cannot define a
> constructor, the doc makes it clear that the first
> constructor above is expected as part of the interface.
> Unfortunately (for our collections support project), there is
> already a Rexx(Rexx) constructor with different behavior than
> the interface requires (copy the key==> value mappings during
> initialization) so I added the second constructor to allow
> the same behavior with Rexx Maps. It is actually slightly
> more flexible since the two Rexx parms don't have to be the
> same - the default value is copied from the first parm and
> the maps from the second. There is currently no documentation
> for the NetRexx implementation of the Java Map interface
> other than that provided by the Java documentation for three reasons:
> (1) The Java documentation covers it reasonably well. (2) The
> NetRexx documentation process was in transition last year
> when we developed this code. (Not sure if that has changed
> yet - I haven't actually seen any documentation explaining
> the current NetRexx documentation update
> process.) (3) I did not want to put a lot of work into
> documenting an experiment that might still be thrown out for
> something else. (Of course, René seems to be actually using
> this support for work while he tests it. ;-)

Makes a bit more sense now.

[snip]

> >> Likewise, all NetRexx data items are fundamentally strings, so why
> >> would we want to add non-string objects to Rexx variables?
> > Rexx constructors allow non-string primitives as inputs
> > (ints, floats, etc.).
> > Pretty much essential for conversions & casts etc.
> >  
> I meant that in theory a Rexx object is a string, even if it
> is a number. I am aware that it may not be stored that way
> under the covers since I have read the code.

OK (although that argument would also ague against exposing a Rexx collection as
a Map?).

> >> Also, I made a deliberate choice to only propose a single new
> >> constructor method to avoid overwhelming the mailing list
> >> readers but
> >> I visualized a more comprehensive set of methods allowing easy
> >> reversal of the construction process (Rexx==>array), etc. The new
> >> collections Map interface already has some support for this.
> >> (Rexx.keySet, Rexx.values,
> >> etc.) Can you suggest any additional specific signatures
> >> that might be needed?
> > As you say, there are many possible signatures.   If the
> > basic Rexx constructors
> > allow (say) ints for a string, then why not  Rexx(int[],
> > String[]) and
> > all the other combinations of the accepted primitives
> >(Rexx(String[],
> > int[]), Rexx(int[], float[]), etc.)?
>
> After NetRexx was written and finalized, Java finally
> realized that it needed to support more complex data types
> than the primitive types and so the collections framework was
> added to support things similar to the Rexx indexed
> collection that you had already built into NetRexx
> (apparently you had more foresight than the Java designers
> ;-). I suspect that if the collections framework had existed
> at NetRexx design time, you would have added built in support
> for interacting with that as well as with the primitive Java
> datatypes.

Probably not .. the primitives were added under the 'binary' concept; Java
objects in general would not have come under that category (that's partly why I
didn't add I/O -- assumed people would want to use Java classes 'raw').

> Something that both Java and NetRexx are missing (IMHO) is
> the ability to initialize a map from a set of keys and a
> related set of values without needing to write a separate
> loop for each case like everyone in the world has to do now.
> That is why I made the proposal that started this thread.
> Obviously the proposal can be improved but I don't think it
> should be thrown out casually.

I agree the function is a good one -- I was just questioning why it has to be in
the runtime.  

> >>> Why not keep it/them outside the Rexx class entirely?
> >>> Perhaps have a
> >>> RexxIndexer class or some such.
> >>
> >> Because then I would have to track a separate library jar and make
> >> sure it reaches all appropriate projects and classpaths and gets
> >> converted to dex and downloaded to all Android devices using my
> >> NetRexx applications.
> >> It would be easier to just put the code in each
> >> application but then
> >> the whole idea of code simplification that I am proposing
> >> there goes out the window doesn't it?
> > Instead I think you are proposing to bloat the 'minimal runtime' --
> > which was kept small because it has to be downloaded on
> > slow GPRS links and the like to
> > browsers.   That's why the Rexx runtime classes are split
> > up into several pieces
> > so that if (for example) you'er not using PARSE then all
> > the code for that doesn't have to be dragged down to the
> > application/browser.  But
> > anything added to the Rexx class itself is permanent bloat,
> > downloaded by all users of the Rexx datatype.
>
> I don't think this is an issue these days. I doubt that many
> NetRexx apps are dynamically downloaded, browser or
> otherwise. More likely they are installed on a device and run
> from there like on Android. I do keep the runtime size in
> mind always however even though memory and bandwidth
> requirements change with time.

OK.

[snip]

> > That's why I suggested putting this kind of thing into a different
> > 'Rexx additions for cunning purposes' class rather than  is
> > shoveling everything into the primitive Rexx class (which is already
> > too big/complex, some have argued).
>
> To some extent this may be possible but the problem is that
> NetRexx treats Rexx objects differently from other objects.
> You cannot use indexed access (ie x[y]) on a subclass of Rexx
> or any other item except a Java array and with those you have
> no direct access to Rexx methods. I tried to add some support
> for subclassing Rexx in the experimental version of NetRexx
> but if anyone had bothered to look at the example code I
> provided at the beginning of this thread, they would see that
> it still has flaws: compiled code does not always recognize a
> Rexx subtype and forces you to manually convert to a string
> to use it as an index and interpreted code does not recognize
> such a constructor with a default Rexx parm. I don't know the
> code well enough to fix those problems. It would be nice if
> NetRexx could recognize subclasses of Rexx and allow use of
> everything that it provides for Rexx variables. Even then I
> object to adding extra jar files to my applications besides
> the NetRexxR.jar just to support advanced language features.
> Maybe there is a compromise possible there.

Might be worth exploring, indeed.
 
[Reply to later posts .. later .. a bit behind at the moment.]

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 
[snip]

> This allows both approaches to be tested at the same time and
> provides two options in case future sentiment shifts towards
> adding more advanced Java support to an official release of
> NetRexx. Usage is as follows:
>
>          Rexx(keys, values, default)
>          RexxUtil.getRexx(keys, values, default)
>
> where keys and values are any arrays or Java collections
> framework Lists and default is an optional object to provide
> a default value for the Rexx variable. All elements are
> converted to strings before being added to the indexed Rexx
> variable which is returned. Null can be passed for one of the
> keys or values parameters to default to a 1-n integer
> sequence matching the other parameter but if both parameters
> are provided they must have the same length. Note that arrays
> do not need to be string arrays and that primitive arrays
> such as int[] are also accepted.

Nice; overall this 'feels' more elegant a solution than starting to introduce
support for a possibly never-ending collection of Collections and other Objects
... :-)

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jason Martin]

It sounds good to me at the moment too.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Mike ... There ...

(and all, when you could *try to listen, please*) :

When you, as the Father of Rexx, and also NetRexx, *did invent* NetRexx,
as a new *Language*
of this always *exciting* FAMILY of Rexx Languages, years, and
decenniums, ago.

At those times, there have been only the Following Rexx Dialects
available (as far as I do know):

Classic Rexx, as implemented as SNA Rexx, on all IBM Machines.
REGINA, as the *one, and only one* RELIABLE installation of ANSII Rexx.
Object Rexx, as Designed by Rick Mc Guirre, and others ...

and then:
*Your NetRexx*.

At those times, so called *HashMaps* have been the only provided mechanisms
*for Collections* (at least, in Java, thus you *did decide, to use that!

Now, as I can see (from your source-code, dear Mike), you did have, at
your initial
trials, a *class* called *RexxNum*, which you did *merge* into *class Rexx*,
as well as the nowadays called *Indexed Strings*, which have been called
*Stems* in the original (and any and all) former rexx Languages.

Frankly speaking, from my side, you did make 1, and only 1, fault, from
the very beggining
of the DESIGN of any & all Rexx dialects:

1,23  *is NOT* "1,23"

Those two things do have a *totally Different* meaning to *all human
Beeings:

1,23   is a Decimal Number (aI do call them: Numeric)

*and*

"1,23" is a String (I do call them Text, by the way)

Now:

Numerics (Numbers (::= Integral Numbers), Positive or Negative) as well
as *Numerics*,
implemented as PACKED FIXED in PL/I, or whatever):

********************************
* Have to be: RIGHT Aligned, with the proper precision
* in any PRINTOUT (or XCEL Spread sheet), or whatever)
********************************

*whilst*

*Texts* have to be *left aligned* (except in Arabic, of course),
and *folded*, when necessary, etc etc.

THUS:

A Number is a Number is a Number,
A Numeric is a Numeric is a Numeric,

*and*

A Text is a Text is a Text!

*and*
A Stem is a Stem is a Stem (is now in NetRexx, an *Indexed String*)

*****************
*BUT
*****************

in classic Rexx, ooRexx (nowadays), and also Regina *sources*:

I can see, from:

a.='abc'   -- in the declaration ...

... that this is a STem!

In NetRexx, with or without options binary:

a = Rexx ''

I *do NOT see*, whether this is a String, *or* a Stem (*or Indexed
String*, however you call it!)

*And*:

This ony point has been *ILL DESIGNED* (maybe by time-pressure ???)

Current Class Rexx.nrx does simply CATER too many possiblilities
*without introducing* the matching *concepts*, as well.

Anyway, nice flights, to you all!

Thomas Schneider.
===============================================================



Am 26.11.2012 15:15, schrieb Mike Cowlishaw:

>  
> [snip]
>
>> This allows both approaches to be tested at the same time and
>> provides two options in case future sentiment shifts towards
>> adding more advanced Java support to an official release of
>> NetRexx. Usage is as follows:
>>
>>           Rexx(keys, values, default)
>>           RexxUtil.getRexx(keys, values, default)
>>
>> where keys and values are any arrays or Java collections
>> framework Lists and default is an optional object to provide
>> a default value for the Rexx variable. All elements are
>> converted to strings before being added to the indexed Rexx
>> variable which is returned. Null can be passed for one of the
>> keys or values parameters to default to a 1-n integer
>> sequence matching the other parameter but if both parameters
>> are provided they must have the same length. Note that arrays
>> do not need to be string arrays and that primitive arrays
>> such as int[] are also accepted.
> Nice; overall this 'feels' more elegant a solution than starting to introduce
> support for a possibly never-ending collection of Collections and other Objects
> ... :-)
>
> Mike
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
http://www.thsitc.com Austria, Europe Skype ID: Thomas.Schneider.Wien
Yahoo ID: [hidden email] FaceBook ID: Thomas.Schneider.Wien Member
of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx
Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/