Proposed constructor
Locked
12
12
 
|
In doing a lot of Android programming lately, I find myself often
needing to convert from the String arrays used by external Java platforms like Android to Rexx variables for my code to use. Often it is OK to simply use the standard String array constructor and select elements using the ".word" bif like this: Rexx(some_string_array).word(n). But that does not work if the strings in the array could have embedded spaces. I would prefer a direct conversion to an indexed Rexx map so I could use simple rexxvar[n] references with full Rexx bif capabilities without having to write a loop each time to convert arrays to Rexx maps. The code below is a sample demonstration of a proposed new constructor for the Rexx class and what it could do. (This code requires the NetRexxC compiler from the "after3.01" advanced development branch: http://kenai.com/projects/netrexx-plus/downloads/download/Experimental%20NetRexx%20Build/NetRexxC.jar ) Although this constructor is not actually part of the new Java collections support it can be considered an extra collections feature that Java itself does not provide to easily create a Java Map. Comments? -- Kermit PS to René - you can add this program to the collections support unit tests or examples if you would like. -------------------------------------------------------------------------- start code ------------------------------------------------------------------------------- /* Program TRexxTest.nrx -- demonstration of proposed new Rexx constructor -- Rexx(String[],String[]) if passed two string arrays of the same length, convert them to an indexed Rexx variable This also creates a Java Map under the proposed collections support in the advanced experimental after3.01 NetRexx branch (Note that this example will not run with NetRexx 3.01 as it uses the experimental collections support mentioned above) */ -- define test string arrays ts1=String "one two three four five" ts1array=ts1.split(" ") ts2=String "a b c d e" ts2array=ts2.split(" ") say "part 1 - a basic map from two string arrays" say "" -- define and display an indexed Rexx variable/map tri=TRexx(ts1array,ts2array) loop y over tri say y "==>" tri[y] end say "" say "part 2 - advanced features=default values and an ordered index" say "" -- now demonstrate creating a numerically ordered map index with a default value -- then dump both maps together and show what is beyond the map boundary tri2=TRexx(null,ts1array,"empty") loop x=1 to tri2.size+1 say x "==>" tri2[x] "==>" tri[tri2[x].toString] end say "" say "part 3 - advanced features=reverse one-based map" say "" -- now demonstrate creating a reverse map of values to Rexx type (one-based) numeric indexes tri3=TRexx(ts1array,null,"empty") loop x over tri3 say x "==>" tri3[x] "==>" tri[tri2[tri3[x]].toString] end -- Here is a Class to demonstrate the new Rexx constructor definition -- (note that the no-default constructor method is not needed in Rexx.nrx itself, likewise the toString above would not be needed with a base Rexx class version) class TRexx extends Rexx method TRexx(s1=String[],s2=String[]) returns TRexx this(s1,s2,"") method TRexx(s1=String[],s2=String[],defaultvalue=Rexx) returns TRexx super(defaultvalue.toString) if s1\=null then if s2\=null then if s1.length\=s2.length then signal BadArgumentException if s1=null then if s2=null then arraylen=0 else arraylen=s2.length else arraylen=s1.length loop i=0 for arraylen if s1=null then this.put(i+1,s2[i]) else if s2=null then this.put(s1[i],i+1) else this.put(s1[i],s2[i]) end -------------------------------------------------------------------------- end code ------------------------------------------------------------------------------- _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
> Rexx constructor -- Rexx(String[],String[]) > if passed two string arrays of the same length, > convert them to an indexed Rexx variable Understand the desire for this, but worry about how different it is to the Rexx(String[]) constructor. It would also be the first constructor that does not simply generate a Rexx string. Futher, there are a whole series of related special-case operations where (for example) the index strings could be omitted and the indices '0' through length-1 be used, or both arrays might not be of Strings (etc.). It would be best to design the whole as a consistent set of methods, rather than adding bits at a time. Why not keep it/them outside the Rexx class entirely? Perhaps have a RexxIndexer class or some such. If there was just the one and it had to be in the Rexx class then it might be better as a static factory rather than a constructor. Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Thanks for the feedback Mike.
I added some responses/questions below. -- Kermit On 11/18/2012 9:25 PM, Mike Cowlishaw wrote: > >> Rexx constructor -- Rexx(String[],String[]) >> if passed two string arrays of the same length, >> convert them to an indexed Rexx variable > Understand the desire for this, but worry about how different it is to the > Rexx(String[]) constructor. It would also be the first constructor that does > not simply generate a Rexx string. As part of the Collections support that René and I worked on last year, I added two constructors for creating indexed Rexx/Java Map entities: method Rexx(m=Map) method Rexx(r=Rexx,s=Rexx) Those additions are not part of an official release yet, however. Since all existing (released) documented constructors are single argument, I see no confusion from two argument constructors producing maps as I think it would be expected by users. > Futher, there are a whole series of related special-case operations where (for > example) the index strings could be omitted and the indices '0' through length-1 > be used, or both arrays might not be of Strings (etc.). It would be best to > design the whole as a consistent set of methods, rather than adding bits at a > time. I do not see why NetRexx would use Java zero based indexes. Was it not a deliberate choice for NetRexx to use the Rexx style one based indexes? Likewise, all NetRexx data items are fundamentally strings, so why would we want to add non-string objects to Rexx variables? 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? > 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 here goes out the window doesn't it? > If there was just the one and it had to be in the Rexx class then it might be > better as a static factory rather than a constructor. What is the advantage? Isn't it just an indirect constructor then? I think the factory pattern is really only an advantage in this case if you have multiple different results desired from the same parameter types but that implies many methods rather than just one. Maybe I am wrong but I do not see any real objection here other than "we never did it that way before". Do you not want to see any changes at all to NetRexx (even to fix serious problems like the method resolution algorithms have)? Or is it just changes that might impact the syntax complexity that you object to? > Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit,
I'm afraid I must agree with Mike here. See my coments below. 2012/11/19 Kermit Kiser <[hidden email]> Thanks for the feedback Mike. I don't think thinks it is a mater of one versus two or more parameters. I is just, well, it doesn't fit in the language very well. Nor do the collections related constructors you mention either IMO. In your own words "all NetRexx data items are fundamentally strings, so why would we want to add non-string objects to Rexx variables" except that Rexx indexed string elements are in fact Rexx strings (not java.lang.Strings) which in tur can be indexed and so on. NetRexx as a language has been up to now independent of the java language or infrastructure. The fact that someVar="some text" thanslates to java.lang.String someVar="some text" is just an implementation detail. It should never contribute to shape the language in any way. Under this light Rexx(m=Map) makes no sense at all, Map is not a NetRexx intrinsic but just a java thing which happens to be available on the reference implementation. Why should we start polluting NetRexx's fundamental type, its cornerstone, with alien elements? Ok, there is convenience. Sou are an Android programer, what about CharSequences? You got a lot of those in Android land. I had the disgrace to be a lotus Domino developer time ago. That API returned Vectors everywhere. Should I advocate for a Rexx(Vector, Vector) constructor at the time? By now I'd be advocating for a Rexx(List, List) one of course. Honestly, I think there are better ways to handle the "boiler plate code" problem than littering the NetRexx fundamentalt ype's API with more and more platform specific code which has nothing to do whatsoever with the language itself.
Good question indeed...
IMHO that convenience/utility stuff belongs to a RexxUtil class (along some basic date/time processing methods and constants). I'd advocate for also putting in some constants like TRUE and FALSE to be universally available. If tooling is really that lacking as you seem to convey, then you might have a case for inclusion of said class in the runtime package.
The Rexx type constructor collection remains composed only from constructors taking just arguments of NetRexx types. 1, 1.3 and 'text' are all of Rexx type in NetRexx not Integer, Float and String. OTH you still get the convenience of getting a new Rexx object inialized from a Map, a couple of String arrays or whatever without having to write a loop. RexxUtil.getRexx(Map) RexxUtil.getRexx(String[], String[]) RexxUtil.getRexx(java.util.Date) RexxUtil.getRexx(Rexx, Rexx) ... ad nauseam.. You get the best of two worlds. Hell, NetRexx even haves the "uses" instruction so you can save typing the 9 characters in "RexxUtil." IMO adopting those constructors is a quite radical change in paradigm. NetRxx would go from providing access to the java library to consuming, hence depending on, that library itself. Isn't it just an indirect constructor then? I think the factory pattern is really only an advantage in this case if you have multiple different results desired from the same parameter types but that implies many methods rather than just one. I hope I've presented one. Here is another: The problem with convenience stuff is that every one needs crosses of a different size and shape. When you start catering for everybody the end result is often something which is convenient for no one. Do you not want to see any changes at all to NetRexx (even to fix serious problems like the method resolution algorithms have)? Or is it just changes that might impact the syntax complexity that you object to? -- Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
Kermit, thanks for the quick reply.
> Thanks for the feedback Mike. > > I added some responses/questions below. > > -- Kermit > > On 11/18/2012 9:25 PM, Mike Cowlishaw wrote: > > > >> Rexx constructor -- Rexx(String[],String[]) > >> if passed two string arrays of the same length, > >> convert them to an indexed Rexx variable > > Understand the desire for this, but worry about how > > different it is to the > > Rexx(String[]) constructor. It would also be the first constructor > > that does not simply generate a Rexx string. > > As part of the Collections support that René and I worked on > last year, I added two constructors for creating indexed > Rexx/Java Map entities: > > 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? > Those additions are not part of an official release yet, > however. Since all existing (released) documented > constructors are single argument, I see no confusion from two > argument constructors producing maps as I think it would be > expected by users. Well, not expected by me because I don't know what a 'Map' is :-). In NetRexx2, Rexx(...) constructors only use Java 'primitives'. Adding more complex objects asks how far does one go .. should one include Rexx contructors that take arbitrary objects and somehow map them to indexed strings? Arrays of windows indexed by their titles might be very handy, for example, .. but should that be in the Rexx class? Also if you already have a two-argument constructor proposed .. how does the array version work (arrays of Rexx for the two arguments)? > > Futher, there are a whole series of related special-case operations > > where (for > > example) the index strings could be omitted and the indices '0' > > through length-1 be used, or both arrays might not be of Strings > > (etc.). It would be best to design the whole as a > > consistent set of > > methods, rather than adding bits at a time. > > I do not see why NetRexx would use Java zero based indexes. > Was it not a deliberate choice for NetRexx to use the Rexx > style one based indexes? I was suggesting that as an example of where the concept leads .. an array of objects in Java is indexed from 0, and so "naturally" automatic assigning to indices should probably use base 0. But as you say, that's a bad idea. > 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. > 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.)? > > 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 here 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. > > If there was just the one and it had to be in the Rexx > > class then it > > might be better as a static factory rather than a constructor. > > What is the advantage? Isn't it just an indirect constructor > then? I think the factory pattern is really only an advantage > in this case if you have multiple different results desired > from the same parameter types but that implies many methods > rather than just one. I think in effect you are proposing a lot more than one. > Maybe I am wrong but I do not see any real objection here > other than "we never did it that way before". Do you not want > to see any changes at all to NetRexx (even to fix serious > problems like the method resolution algorithms have)? Or is > it just changes that might impact the syntax complexity that > you object to? I primarily object to complexity. 'Under the covers' is fine -- clever stuff that hides horrible mechanisms or syntax from users is good. Adding dozens of methods to basic classes (like Rexx) means that every user has to plough through that documentation -- and understand them all -- before they can really start to feel they are comfortable with that class. 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). Another approach would be to have a 'RexxExperimental' class with various things in it. Once they have been in use for a while and shown to be widely used, reliable, and useful, then consider 'promoting' them into the base class (leaving them in the Experimental class, too, so as not to break anything). Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by David Requena
Not that I myself ever have any problem of discussing all things out in
the open, but the ARB list would have, formally, been more appropriate for this. Rexx has always been a part of very different software ecosystems; I think that everyone can see that VM, or ISPF or JSP, curses or Java Swing, or NetView, are environments that have not a lot in common if we rise above the bits and bytes and abi levels. Furthermore, it runs on wildly different instruction sets. This causes some problems of balance when trying to provide support for one of those environments, in this case (almost) Java on Android, or Java Collection classes on the JVM. It is easy and elegant to do things in (Net)Rexx only, the problem comes into existence when combining the environmental things. The SAA Api came into being on VM and TSO and when Rexx only consisted of strings. It was conceived to easier interact, from that point of view, with the environment at that level of development- easier external functions, embeddability of Rexx macro's. In NetRexx we don't have this API interface because the environent is supposed to be Java- the JVM and class libraries, and the functionality left out is what Java offers. This goes for Collection classes, for example: there is a wider pallette of function available that in NetRexx; I/O is entirely absent from NetRexx except for the console device; for files and network I/O it depends on the JVM class library. When doing a lot of data dependent work, we hit the point where NetRexx delivers some native support (be it dependent on some older incarnations or Directory or HashMap or other pre-collection classes) but the JVM collection classes are tempting, or sometimes necessary. David's point that type Rexx is not String is here the reason for a lot of needless notation and casting, going against the philosophy of small and unsurprising. Type inference is one of the mechanisms employed for this - remember all those tedious type duplications going on in Java and C++. I would say that if an added interface supports the notion of type inference, we should support it. Exactly how we support it, is, in the proven tradition of designing first, agreeing and implementing, something for the ARB and its language architect (Mike - who's role it is to be conservative) to decide. The form in which to package it (as part of type Rexx, or as a separate xxSupport package, or something else entirely (a preprocessor - shudder) or a subtype of Rexx) is up for discussion and decision in the ARB. None of this should ever keep someone from whipping up a prototype - abstract discussions are mostly abstract. Then, each solution should pass unit- and regression testing before it can be considered for inclusion. Inclusion should be carefully planned, introduced and vetted in release candidates. So this discussion should at least include: 1) cost 2 usability for different API 3 is it 'in the spirit' - does it simplify through type inference - does it keep the language small or make it even smaller 4) is the design discussed and agreed upon 5) does it complicate installation 6) does it pass it unit test 7) does it pass the regression tests 8) is it downward compatible I am looking forward to this discussion in the ARB. I have an interest in smoother integration of the Collection classes; the prototype works very well, to the point that I have a combination of released/unreleased code for running my day to day work. We must determine the boundaries here and decide what to include and when. best regards, Rene Jansen. On 2012-11-20 00:48, David Requena wrote: > Kermit, > > I'm afraid I must agree with Mike here. > See my coments below. > > 2012/11/19 Kermit Kiser <[hidden email] [1]> > >> Thanks for the feedback Mike. >> >> I added some responses/questions below. >> >> -- Kermit >> >> On 11/18/2012 9:25 PM, Mike Cowlishaw wrote: >> >>> >>> >>>> Rexx constructor -- Rexx(String[],String[]) >>>> if passed two string arrays of the same length, >>>> convert them to an indexed Rexx variable >>> Understand the desire for this, but worry about how different it >>> is to the >>> Rexx(String[]) constructor. It would also be the first >>> constructor that does >>> not simply generate a Rexx string. >> As part of the Collections support that René and I worked on last >> year, I added two constructors for creating indexed Rexx/Java Map >> entities: >> >> method Rexx(m=Map) >> method Rexx(r=Rexx,s=Rexx) >> >> Those additions are not part of an official release yet, however. >> Since all existing (released) documented constructors are single >> argument, I see no confusion from two argument constructors >> producing maps as I think it would be expected by users. > > I don't think thinks it is a mater of one versus two or more > parameters. I is just, well, it doesn't fit in the language very > well. > Nor do the collections related constructors you mention either IMO. > > In your own words _"__all NetRexx data items are fundamentally > strings, so why would we want to add non-string objects to Rexx > variables"_ except that Rexx indexed string elements are in fact REXX > STRINGS (not java.lang.Strings) which in tur can be indexed and so > on. > > NetRexx as a language has been up to now independent of the java > language or infrastructure. The fact that someVar="some text" > thanslates to java.lang.String someVar="some text" is just an > implementation detail. It should never contribute to shape the > language in any way. > > Under this light Rexx(m=Map) makes no sense at all, Map is not a > NetRexx intrinsic but just a java thing which happens to be available > on the reference implementation. Why should we start polluting > NetRexx's fundamental type, its cornerstone, with alien elements? > > Ok, there is convenience. Sou are an Android programer, what about > CharSequences? You got a lot of those in Android land. > I had the disgrace to be a lotus Domino developer time ago. That API > returned Vectors everywhere. Should I advocate for a Rexx(Vector, > Vector) constructor at the time? By now I'd be advocating for a > Rexx(List, List) one of course. > > Honestly, I think there are better ways to handle the "boiler plate > code" problem than littering the NetRexx fundamentalt ype's API with > more and more platform specific code which has nothing to do > whatsoever with the language itself. > >>> Futher, there are a whole series of related special-case >>> operations where (for >>> example) the index strings could be omitted and the indices '0' >>> through length-1 >>> be used, or both arrays might not be of Strings (etc.). It >>> would be best to >>> design the whole as a consistent set of methods, rather than >>> adding bits at a >>> time. >> I do not see why NetRexx would use Java zero based indexes. Was it >> not a deliberate choice for NetRexx to use the Rexx style one based >> indexes? Likewise, all NetRexx data items are fundamentally strings, >> so why would we want to add non-string objects to Rexx variables? > > Good question indeed... > > 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==&g > >> you suggest any additional specific signatures that might be needed? >> >>> 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 here goes out the window doesn't it? >> >> IMHO that convenience/utility stuff belongs to a RexxUtil class >> (along some basic date/time processing methods and constants). I'd >> advocate for also putting in some constants like TRUE and FALSE to >> be universally available. > really that lacking as you seem to convey, then you might have a > case > for inclusion of said class in the runtime package. > > > > If there was just the one and it had to be in the Rexx class then it > might be > better as a static factory rather than a constructor. > What is the advantage? > > The Rexx type constructor collection remains composed only from > constructors taking just a > >> rier new,monospace">'text' are all of Rexx type in NetRexx not >> Integer, Float and String. OTH you still get the convenience of >> getting a new Rexx object inialized from a Map, a couple of String >> arrays or whatever without having to write a loop. >> >> RexxUtil.getRex > pan>RexxUtil.getRexx(String[], String[]) > RexxUtil.getRexx(java.util.Date) > RexxUtil.getRexx(Rexx, Rexx) > ... ad nauseam.. > > You get the best of two worlds. Hell, NetRexx even haves the "uses" > instruction so you can save typing the 9 characters in "RexxUtil." > > IMO adopting those constructors is a quite radical change in > paradigm. > NetRxx would go from providing access to the java library to > consuming, hence depending on, that library itself. > > Isn't it just an indirect constructor then? I think the factory > pattern is really only an advantage in this case if you have multiple > different results desired from the same parameter types but that > implies many methods rather than just one. > > Maybe I am wrong but I do not see any real objection here other than > "we never did it that way before". > > I hope I've presented one. Here is another: > > The problem with convenience stuff is that every one needs crosses of > a different size and shape. When you start catering for everybody the > end result is often something which is convenient for no one. > > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [2] _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Mike Cowlishaw
Rexx(...) constructors only use Java 'primitives'. Adding more complex objects asks how far does one go ... Great discussion. I haven't heard (or noticed) this explicitly enunciated before, but it sounds like a powerful principle to protect NetRexx from being embarrassed by future changes in Java.On Tue, Nov 20, 2012 at 9:27 AM, Mike Cowlishaw <[hidden email]> wrote: Kermit, thanks for the quick reply. -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
George,
true. It is also the case that the compiler does not use the runtime, as far as I know, to avoid circularity and worse. On the other hand, nothing in Java can be considered invariant; the underpinnings of NetRexx include the older collection classes like directory and vector. These turned out to be synchronized and much slower than needed for most applications. The threading api was deprecated after some time because the atomic operations were broken. We must be prepared for other things to happen. One of the lines of defence is to always link to interfaces and control these ourselves - so we can fix things if java semantics change. We must formalize these notions as soon as we are exactly sure what they are. best regards, René. On 2012-11-20 16:33, George Hovey wrote: > Rexx(...) constructors only use Java 'primitives'. Adding more > complex objects asks how far does one go ... > > Great discussion. I haven't heard (or noticed) this explicitly > enunciated before, but it sounds like a powerful principle to protect > NetRexx from being embarrassed by future changes in Java. > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
> true. It is also the case that the compiler does not use the
> runtime, as far as I know, to avoid circularity and worse. On > the other hand, nothing in Java can be considered invariant; > the underpinnings of NetRexx include the older collection > classes like directory and vector. > These turned out to be synchronized and much slower than > needed for most applications. The threading api was > deprecated after some time because the atomic operations were > broken. We must be prepared for other things to happen. One > of the lines of defence is to always link to interfaces and > control these ourselves - so we can fix things if java > semantics change. We must formalize these notions as soon as > we are exactly sure what they are. Good points. Just to be clear .. it is entirely "proper and reasonable" that the compiler and runtime implementation make use of Java enhancements and new classes and the like to provide the best performance and overall 'experience' to the NetRexx programmer and user. NetRexx (as a language) comprises two main layers: * 'Pure NetRexx' .. which is a language based on the Rexx datatype, and which closely follows the Java object model. * 'Binary extensions' .. which allow NetRexx programs to use the Java binary types efficiently (and even to create programs that don't use the Rexx datatype at all). These datatypes are quite universal -- outside Java as well, of course -- so a NetRexx -> C translater/compiler should be doable, too. What I am muttering about is the suggestion that the 'extensions' layer might start to include Java objects as 'primitive datatypes' .. which would make NetRexx a Java-dependent language, rather than a language that happens to use the Java object model (and therefore runs efficiently on that platform). All somewhat academic, of course. In the late 1990s it really did seem that the world was converging on a single object model (just as it had converged on 'the way' to do to arithmetic). But object models, unfortunately, have diverged as rapidly as Linux distributions; Javascript perhaps the worst culprit. Thanks to Android, Java now looks as though it will have a long life ahead of it in addition to the 'corporate' environment. But I still think it is worth keeping the 'clean' design aspects of NetRexx: core language, binary enhancements for efficiency, and everything else in a third category. Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by David Requena
David --
Thanks for sharing your thoughts. I am not sure why anyone would be afraid to agree with Mike however. And I am not afraid to disagree with Mike either. I am sure he is a nice guy although I only met him once or twice at Share. Unfortunately, intimidating opinions from authority figures can easily shut down discussion or prevent people from sharing new ideas. I did not mean to start a language philosophy war of some kind, but if that is the direction the discussion is taking then I feel we should start with some facts. I have worked quite a bit on the Rexx.nrx module so I have some familiarity with it. The current official release has 15 constructors, 13 of which are documented in the NRL3 doc. Two of the constructors could be termed "native" NetRexx constructors while 13 of the constructors are for converting Java data types into NetRexx data objects. (One is for internal use only.) Here is the constructor list from the source code: C:\NetRexx\repository\netrexxc\trunk\src\netrexx\lang\Rexx.nrx method Rexx(inchar=char) method Rexx(in=char[]) method Rexx(string=java.lang.String) method Rexx(tcs=java.lang.CharSequence) method Rexx(strings=java.lang.String[]) method Rexx(in=Rexx) method Rexx(flag=boolean) method Rexx(num=byte) method Rexx(num=short) method Rexx(num=int) method Rexx(num=long) method Rexx(num=float) method Rexx(num=double) method Rexx(s=char[], trynum=boolean) shared method Rexx() shared; super(); return Currently the only two parameter constructor is reserved for internal use and the only 0 parameters constructor is the default Rexx() constructor. That boils down to 2 native constructors versus 12 constructors dealing with Java data types. (BTW - Notice that one of the constructors is the CharSequence one that you mentioned. It was added last year when it became evident that Java as well as Android was switching all interfaces from using String to CharSequence parameters. The actual support added goes well beyond the constructor as there are automatic conversion algorithms and costs in various places also. The new constructor has not yet been added to the documentation but full support is there now.) I shared the above information because I have noticed the idea expressed by several people that NetRexx is a totally Java independent language that happens to inter-operate with Java but could just as well work with other languages and needs to be kept in some sort of separate and "pure" state. Perhaps there is also some idea out there that Java is just a passing fad and NetRexx will need to be converted to work with another language at some time in the future. I have a different view and I am going to be bold and state it quite bluntly here. Java is not going away. Android has made sure of that in the last year or two. Java is not just a niche language for server apps now but a mainstream end-user application framework that is threatening to blow away everything else. NetRexx on the other hand is very little known and may well fade away when we old-timers do. We market NetRexx as a better way to do Java programing and we hope to attract new users from the Java programmer ranks for that use. I use NetRexx almost exclusively for my development work, both commercial and open source Java based projects. I suspect that most of those who actually use NetRexx professionally use it for the same purpose - easier Java programming. To be both blunt and honest - I don't give a damn about some theoretical NetRexx independent of Java. I want to be able to run my code anywhere there is a JVM or something compatible like Dalvik. I want to have a competitive advantage over programmers who exclusively use Java. I want NetRexx to survive and grow and adapt. I like being able to code amazing stuff overnight. I need NetRexx to be as compatible and inter-operable as possible with Java! But better than Java and much faster to develop in. There are younger languages than NetRexx that also aim to be a better way to do Java programming and some are quite well known like JRuby, Jython and Groovy. Check the Wikipedia entry and you will see that NetRexx is not listed among the well known JVM languages. (http://en.wikipedia.org/wiki/List_of_JVM_languages) It is an "also ran". I will concede that NetRexx has faltered in part because it was proprietary and closed-source and not well maintained for most of it's life. But I wonder if the real reason that other JVM languages have become more popular than NetRexx is because they have grown and adapted to the needs and desires of their user base. While I am being honest I must confess that I have not used the official NetRexx release (3.00 or 3.01) for any of my work for over a year now. It is just too broken in Java interoperability and lacking in needed features to support any advanced work. This discussion is therefore no skin off my nose - I will simply continue to add new features to the experimental branch of NetRexx and let the authorities pick and choose what they want to merge into the official releases someday. If NetRexx survives, that is. I do wonder though if we will attract many new users from the Java ranks in the current state of things. Our developer tools are primitive. Inherited Java method calls resolve quite differently than in Java and some Java classes cannot be extended or properly used at all. There is no support for enums (don't even mention generics!). There is no JSR223 or JSR199 interface. Etc. So we can continue to argue over adding more convenience methods to inter-operate with Java and the theory of being an independent language while NetRexx fades into the sunset. Meanwhile when something better than Java comes along for development, I am betting that it won't involve coding at all, at least as we know it now. Maybe we will just do a "dance" in front of a Kinect and a computer will interpret it and write an application for us! (Don't take that one too seriously. ;-) What may have made sense a decade ago no longer does. Just my $.02 and worth every penny... -- Kermit On 11/19/2012 1:48 PM, David Requena
wrote:
Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
+1 :-) Thomas.
================================================================== Am 21.11.2012 10:52, schrieb Kermit Kiser: David -- --
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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by Kermit Kiser
Kermit,
I quite like long exchanges as long as we solve a problem in the end. Also, there is no shutting down of any discussion - discussions need to run their course. This is a very interesting subject, and it shows how simplicity and conceptual integrity can be at odds sometimes, as they are now in the collection class and android support design. The beauty of open source is that we can all have our own version of NetRexx, and indeed, as stated earlier, I am running with a unique mixture. It is also my task as project manager to make sure there is an official version that most of us will use and that is adequately supported. I agree with you on the missed opportunities for openness earlier; I used JRuby, Jython and Groovy at some time or other, and they are no pleasure, and even if they were, their performance is generally a step back from what we are used to. I can understand Mike's position here clearly - his role is to be conservative and suggest alternatives. Also, we need not forget that NetRexx started as a multi-language compiler engine (this explains the 'babel' references all over the sourcecode) and we know some deep thought has gone into this. You are absolutely right that the JVM is the only place that NetRexx runs nowadays, there were some allusions over the years that Mike was contemplating a native code compiler (via C probably) but it did not surface yet. I am confident he has the most complete picture of what constitutes Rexx and what is to be considered 'runtime' - this is not relative to the current JVM implementation, but to the historical intent. Yet the drive for simplicity prompts us to consider mixing the language more with the runtime. As I persuaded Rony some years ago to drop the strict typing between java.lang.String and type Rexx in Bsf4ooRexx (then bsf4rexx) (there is now special treatment that avoids casting to and fro, if the ooRexx object needs to be a NetRexx Rexx type - the same methods work). As I have said before, proper, runtime supported treatment of type Rexx for the java collection framework can prevent the notation-and-compiler-technology-heavy and runtime-light, not to say ugly, generics mess of java. The alternative would be to come up with our own collection framework or borrow the one from ooRexx and implement on the JVM. Bonus points for the brave person who uses llvm, emscripten and a js-to-java tool to automate it. Personally, I am not opposed to polluting NetRexx with Java notions as long as the separation is clear. We could define an interface for the existing Rexx class, and add support for other things by adding another interface to the concrete type. When we look at the categories in Mike's previous email, we should actionally re-package the Runtime into pure NetRexx and Java-binary interfaces. So, I do agree with both views, and I think we should move forward- that is the only useful direction. On 2012-11-21 10:52, Kermit Kiser wrote: > David -- > > Thanks for sharing your thoughts. I am not sure why anyone would be > afraid to agree with Mike however. And I am not afraid to disagree > with Mike either. I am sure he is a nice guy although I only met him > once or twice at Share. Unfortunately, intimidating opinions from > authority figures can easily shut down discussion or prevent people > from sharing new ideas. > > I did not mean to start a language philosophy war of some kind, but > if that is the direction the discussion is taking then I feel we > should start with some facts. I have worked quite a bit on the > Rexx.nrx module so I have some familiarity with it. The current > official release has 15 constructors, 13 of which are documented in > the NRL3 doc. Two of the constructors could be termed "native" > NetRexx > constructors while 13 of the constructors are for converting Java > data > types into NetRexx data objects. (One is for internal use only.) Here > is the constructor list from the source code: > > C:NetRexxrepositorynetrexxctrunksrcnetrexxlangRexx.nrx > method Rexx(inchar=char) > method Rexx(in=char[]) > method Rexx(string=java.lang.String) > method Rexx(tcs=java.lang.CharSequence) > method Rexx(strings=java.lang.String[]) > method Rexx(in=Rexx) > method Rexx(flag=boolean) > method Rexx(num=byte) > method Rexx(num=short) > method Rexx(num=int) > method Rexx(num=long) > method Rexx(num=float) > method Rexx(num=double) > method Rexx(s=char[], trynum=boolean) shared > method Rexx() shared; super(); return > > Currently the only two parameter constructor is reserved for > internal use and the only 0 parameters constructor is the default > Rexx() constructor. That boils down to 2 native constructors versus > 12 > constructors dealing with Java data types. > > (BTW - Notice that one of the constructors is the CharSequence one > that you mentioned. It was added last year when it became evident > that > Java as well as Android was switching all interfaces from using > String > to CharSequence parameters. The actual support added goes well beyond > the constructor as there are automatic conversion algorithms and > costs > in various places also. The new constructor has not yet been added to > the documentation but full support is there now.) > > I shared the above information because I have noticed the idea > expressed by several people that NetRexx is a totally Java > independent > language that happens to inter-operate with Java but could just as > well work with other languages and needs to be kept in some sort of > separate and "pure" state. Perhaps there is also some idea out there > that Java is just a passing fad and NetRexx will need to be converted > to work with another language at some time in the future. I have a > different view and I am going to be bold and state it quite bluntly > here. > > Java is not going away. Android has made sure of that in the last > year or two. Java is not just a niche language for server apps now > but > a mainstream end-user application framework that is threatening to > blow away everything else. NetRexx on the other hand is very little > known and may well fade away when we old-timers do. > > We market NetRexx as a better way to do Java programing and we hope > to attract new users from the Java programmer ranks for that use. I > use NetRexx almost exclusively for my development work, both > commercial and open source Java based projects. I suspect that most > of > those who actually use NetRexx professionally use it for the same > purpose - easier Java programming. To be both blunt and honest - I > don't give a damn about some theoretical NetRexx independent of Java. > I want to be able to run my code anywhere there is a JVM or something > compatible like Dalvik. I want to have a competitive advantage over > programmers who exclusively use Java. I want NetRexx to survive and > grow and adapt. I like being able to code amazing stuff overnight. I > need NetRexx to be as compatible and inter-operable as possible with > Java! But better than Java and much faster to develop in. > > There are younger languages than NetRexx that also aim to be a > better way to do Java programming and some are quite well known like > JRuby, Jython and Groovy. Check the Wikipedia entry and you will see > that NetRexx is not listed among the well known JVM languages. > (http://en.wikipedia.org/wiki/List_of_JVM_languages [2]) It is an > "also ran". I will concede that NetRexx has faltered in part because > it was proprietary and closed-source and not well maintained for most > of it's life. But I wonder if the real reason that other JVM > languages > have become more popular than NetRexx is because they have grown and > adapted to the needs and desires of their user base. > > While I am being honest I must confess that I have not used the > official NetRexx release (3.00 or 3.01) for any of my work for over a > year now. It is just too broken in Java interoperability and lacking > in needed features to support any advanced work. This discussion is > therefore no skin off my nose - I will simply continue to add new > features to the experimental branch of NetRexx and let the > authorities > pick and choose what they want to merge into the official releases > someday. If NetRexx survives, that is. > > I do wonder though if we will attract many new users from the Java > ranks in the current state of things. Our developer tools are > primitive. Inherited Java method calls resolve quite differently than > in Java and some Java classes cannot be extended or properly used at > all. There is no support for enums (don't even mention generics!). > There is no JSR223 or JSR199 interface. Etc. > > So we can continue to argue over adding more convenience methods to > inter-operate with Java and the theory of being an independent > language while NetRexx fades into the sunset. Meanwhile when > something > better than Java comes along for development, I am betting that it > won't involve coding at all, at least as we know it now. Maybe we > will > just do a "dance" in front of a Kinect and a computer will interpret > it and write an application for us! (Don't take that one too > seriously. ;-) What may have made sense a decade ago no longer does. > > Just my $.02 and worth every penny... > > -- Kermit > > On 11/19/2012 1:48 PM, David Requena wrote: > >> Kermit, >> >> I'm afraid I must agree with Mike here. >> See my coments below. >> >> 2012/11/19 Kermit Kiser <[hidden email]> >> >>> Thanks for the feedback Mike. >>> >>> I added some responses/questions below. >>> >>> -- Kermit >>> >>> On 11/18/2012 9:25 PM, Mike Cowlishaw wrote: >>> >>>>> Rexx constructor -- Rexx(String[],String[]) >>>>> if passed two string arrays of the same length, >>>>> convert them to an indexed Rexx variable >>>> Understand the desire for this, but worry about how different it >>>> is to the >>>> Rexx(String[]) constructor. It would also be the first constructor >>>> that does >>>> not simply generate a Rexx string. >>> As part of the Collections support that René and I worked on last >>> year, I added two constructors for creating indexed Rexx/Java Map >>> entities: >>> >>> method Rexx(m=Map) >>> method Rexx(r=Rexx,s=Rexx) >>> >>> Those additions are not part of an official release yet, however. >>> Since all existing (released) documented constructors are single >>> argument, I see no confusion from two argument constructors producing >>> maps as I think it would be expected by users. >> >> I don't think thinks it is a mater of one versus two or more >> parameters. I is just, well, it doesn't fit in the language very well. >> Nor do the collections related constructors you mention either IMO. >> >> In your own words _"__all NetRexx data items are fundamentally >> strings, so why would we want to add non-string objects to Rexx >> variables"_ except that Rexx indexed string elements are in fact REXX >> STRINGS (not java.lang.Strings) which in tur can be indexed and so on. >> >> NetRexx as a language has been up to now independent of the java >> language or infrastructure. The fact that someVar="some text" >> thanslates to java.lang.String someVar="some text" is just an >> implementation detail. It should never contribute to shape the >> language in any way. >> >> Under this light Rexx(m=Map) makes no sense at all, Map is not a >> NetRexx intrinsic but just a java thing which happens to be available >> on the reference implementation. Why should we start polluting >> NetRexx's fundamental type, its cornerstone, with alien elements? >> >> Ok, there is convenience. Sou are an Android programer, what about >> CharSequences? You got a lot of those in Android land. >> I had the disgrace to be a lotus Domino developer time ago. That API >> returned Vectors everywhere. Should I advocate for a Rexx(Vector, >> Vector) constructor at the time? By now I'd be advocating for a >> Rexx(List, List) one of course. >> >> Honestly, I think there are better ways to handle the "boiler plate >> code" problem than littering the NetRexx fundamentalt ype's API with >> more and more platform specific code which has nothing to do >> whatsoever with the language itself. >> >>>> Futher, there are a whole series of related special-case >>>> operations where (for >>>> example) the index strings could be omitted and the indices '0' >>>> through length-1 >>>> be used, or both arrays might not be of Strings (etc.). It would >>>> be best to >>>> design the whole as a consistent set of methods, rather than >>>> adding bits at a >>>> time. >>> I do not see why NetRexx would use Java zero based indexes. Was it >>> not a deliberate choice for NetRexx to use the Rexx style one based >>> indexes? Likewise, all NetRexx data items are fundamentally strings, >>> so why would we want to add non-string objects to Rexx variables? >> >> Good question indeed... >> >> 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? >> >> Why not keep it/them outside the Rexx class entirely? Perhaps have a >> RexxIndexer class or some such. >> Because then I >> >>> erted 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 here goes out the window doesn't it? >>> >>> IMHO that convenience/utility stuff belongs to a RexxUtil class >>> (along some basic date/time processing methods and constants). I'd >>> advocate for also putting in some constants like TRUE and FALSE to be >>> universally available. >>> If tooling is really that lacking as you seem to convey, then you >>> might have a case for inclusion of said class in the runtime package. >>> >>> If there was just the one and it had to be in the Rexx >> ss then it might be >> better as a static factory rather than a constructor. >> What is the advantage? >> >> The Rexx type constructor collection remains composed only from >> constructors taking just arguments of NetRexx types. 1, 1.3 and 'text' >> are all of Rexx type in NetRexx not Integer, Float and String. OTH you >> still get the convenience of getting a new Rexx object inialized from >> a Map, a couple of String arrays or whatever without having to write a >> loop. >> >> RexxUtil.getRexx(Map) >> RexxUtil.getRexx(String[], String[]) >> RexxUtil.getRexx(java.util.Date) >> >>> or="#0000ff">RexxUtil.getRexx(Rexx, Rexx) >>> ... ad nauseam.. >>> >>> You get the best of two worlds. Hell, NetRexx even haves the "uses" >>> instruction so you can save typing the 9 characters in "RexxUtil." >>> >>> IMO adopting those constructors is a quite radica >> in paradigm. NetRxx would go from providing access to the java >> library to consuming, hence depending on, that library itself. >> >> Isn't it just an indirect constructor then? I think the factory >> pattern is really only an advantage in this case if you have multiple >> different results desired from the same parameter types but that >> implies many methods rather than just one. >> >> Maybe I am wrong but I do not see any real objection here other than >> "we never did it that way before". >> >> I hope I've presented one. Here is another: >> >> The problem with convenience stuff is that every one needs crosses >> of a different size and shape. When you start catering for everybody >> the end result is often something which is convenient for no one. >> >> Do you not want to see any changes at all to NetRexx (even to fix >> serious problems like the method resolution algorithms have)? Or is it >> just changes that might impact the syntax complexity that you object >> to? >> >> Mike >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ [1] >> >> -- >> Saludos / Regards, >> David Requena >> >> _> com">[hidden email] Online Archive : >> http://ibm-netrexx.215625.n3.nabble.com/ [1] >> >>> > > > > Links: > ------ > [1] http://ibm-netrexx.215625.n3.nabble.com/ > [2] http://en.wikipedia.org/wiki/List_of_JVM_languages > > _______________________________________________ > 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/ |
|
|
I think there is far more agreement here than disagreement. And I am certainly
not wanting or trying to 'shut down' any discussion. > I can understand Mike's position here clearly - his role is > to be conservative and suggest alternatives. Also, we need > not forget that NetRexx started as a multi-language compiler > engine (this explains the 'babel' references all over the > sourcecode) and we know some deep thought has gone into this. Indeed (the prefix in the name of the various classes is intended to indicate those parts that are 'generic' -- apply to all languages -- and those that are 'language-specific' [e.g., NetRexx]). The runtime was/is intended to underpin all of the above (and of course be unnecessary for 'binary' programs). I strongly support efforts to make more automatic conversion between the Rexx (as a string) and the String (and related) datatypes. I was cautious about those because it was not clear how the String class would evolve and there are also some method naming conflicts (substring is very different, for example). With the benefit of a more stable Java and hindsight, a better integration of these must be possible. > Personally, I am not opposed to polluting NetRexx with Java > notions as long as the separation is clear. We could define > an interface for the existing Rexx class, and add support for > other things by adding another interface to the concrete > type. When we look at the categories in Mike's previous > email, we should actionally re-package the Runtime into pure > NetRexx and Java-binary interfaces. So, I do agree with both > views, and I think we should move forward- that is the only > useful direction. The Collections discussion is an interesting one. NetRexx (as a language) really only has one kind of collection -- indexed strings -- and from experience that's as about as far as the 'everyday programmer' wants to go. But there is so much more that can be done; I'm just suggesting that going outside the 'simple strings' paradigm is missing quite a lot of the point of Rexx. Much better to have specialist collections, lists, and the like as purpose-designed classes or (Rexx-aware subclasses) of the platform collections rather than accreting ad hoc methods or constructors onto the 'primitive' Rexx datatype. > > Java is not going away. Android has made sure of that in the last > > year or two. Java is not just a niche language for server > > apps now but > > a mainstream end-user application framework that is threatening to > > blow away everything else. (I said the same in an earlier post.) > > To be both blunt and honest - I > > don't give a damn about some theoretical NetRexx > > independent of Java. But it is that separation that keeps the design and syntax clean. It allows other syntaxes to be swapped in if one wishes (Basic-like, Smalltalk-like, and maybe even Perl-like if you really want that). And if it allows that then one can be fairly certain that the overall design is clean. Constructs and add-ons that cross that boundary constrain the language to just one platform. And we all know that [almost all] platforms have shorter lives than languages... > > I do wonder though if we will attract many new users from the Java > > ranks in the current state of things. That has been a valid question since 1997/2000 :-). At that time NetRexx had features that Java did not have (still true now, of course) -- yet did not attract as many users as expected. Sadly, there are few polyglot programmers; most learn one programming language to begin with and are then forever trapped in that 'culture'. Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Mike Cowlishaw
Hi Mike --
Sorry it takes me a while to respond sometimes due to other projects. There are some responses below. -- Kermit On 11/20/2012 4:27 AM, Mike Cowlishaw wrote: > Kermit, thanks for the quick reply. > >> Thanks for the feedback Mike. >> >> I added some responses/questions below. >> >> -- Kermit >> >> On 11/18/2012 9:25 PM, Mike Cowlishaw wrote: >>> >>>> Rexx constructor -- Rexx(String[],String[]) >>>> if passed two string arrays of the same length, >>>> convert them to an indexed Rexx variable >>> Understand the desire for this, but worry about how >>> different it is to the >>> Rexx(String[]) constructor. It would also be the first constructor >>> that does not simply generate a Rexx string. >> As part of the Collections support that René and I worked on >> last year, I added two constructors for creating indexed >> Rexx/Java Map entities: >> >> 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? 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. 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. ;-) > >> Those additions are not part of an official release yet, >> however. Since all existing (released) documented >> constructors are single argument, I see no confusion from two >> argument constructors producing maps as I think it would be >> expected by users. > Well, not expected by me because I don't know what a 'Map' is :-). In NetRexx2, > Rexx(...) constructors only use Java 'primitives'. Adding more complex objects > asks how far does one go .. should one include Rexx contructors that take > arbitrary objects and somehow map them to indexed strings? Arrays of windows > indexed by their titles might be very handy, for example, .. but should that be > in the Rexx class? > > Also if you already have a two-argument constructor proposed .. how does the > array version work (arrays of Rexx for the two arguments)? >>> Futher, there are a whole series of related special-case operations >>> where (for >>> example) the index strings could be omitted and the indices '0' >>> through length-1 be used, or both arrays might not be of Strings >>> (etc.). It would be best to design the whole as a >>> consistent set of >>> methods, rather than adding bits at a time. >> I do not see why NetRexx would use Java zero based indexes. >> Was it not a deliberate choice for NetRexx to use the Rexx >> style one based indexes? > I was suggesting that as an example of where the concept leads .. an array of > objects in Java is indexed from 0, and so "naturally" automatic assigning to > indices should probably use base 0. But as you say, that's a bad idea. > >> 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. > number. I am aware that it may not be stored that way under the covers since I have read the code. >> 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.)? 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. Maybe even including whatever was appropriate from the stuff you just mentioned above. (BTW - it looks to me like all the stuff you mentioned could be easily handles with one constructor slightly more sophisticated that the one I proposed.) With the support for collections iterators and auto casting in Loop Over that was added to NetRexx 3.01 and the Java Map support that we are experimenting with now, we are just beginning to add that advanced support to NetRexx. You might have done it differently than we are. 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. >>> 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 here 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. 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. >>> If there was just the one and it had to be in the Rexx >>> class then it >>> might be better as a static factory rather than a constructor. >> What is the advantage? Isn't it just an indirect constructor >> then? I think the factory pattern is really only an advantage >> in this case if you have multiple different results desired >> from the same parameter types but that implies many methods >> rather than just one. > I think in effect you are proposing a lot more than one. > >> Maybe I am wrong but I do not see any real objection here >> other than "we never did it that way before". Do you not want >> to see any changes at all to NetRexx (even to fix serious >> problems like the method resolution algorithms have)? Or is >> it just changes that might impact the syntax complexity that >> you object to? > I primarily object to complexity. 'Under the covers' is fine -- clever stuff > that hides horrible mechanisms or syntax from users is good. Adding dozens of > methods to basic classes (like Rexx) means that every user has to plough through > that documentation -- and understand them all -- before they can really start to > feel they are comfortable with that class. > > 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). 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. > Another approach would be to have a 'RexxExperimental' class with various things > in it. Once they have been in use for a while and shown to be widely used, > reliable, and useful, then consider 'promoting' them into the base class > (leaving them in the Experimental class, too, so as not to break anything). > > Mike > > > > > > > > > > > > > _______________________________________________ > 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/ |
|
|
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/ |
|
|
In reply to this post by Mike Cowlishaw
May I, please, simply ADD, that, in my *personal opinion*, the Rexx
class (or, the Text class, which I will call it, shall simply *provide* any & all *methods available in Java for Strings*, as a default! ;-) And, of course, vice versa, OPTION BINARY shall & should *convert* the Rexx Text Methods to the proper Java String (or CharSequence) Java Methods, when: OPTION BINARY is inserted in the program after Rapid Development! ;-) Maybe by a PreProcessor *Rexx2Binary* ? Thomas. ================================================== Am 21.11.2012 16:15, schrieb Mike Cowlishaw: > I think there is far more agreement here than disagreement. And I am certainly > not wanting or trying to 'shut down' any discussion. > >> I can understand Mike's position here clearly - his role is >> to be conservative and suggest alternatives. Also, we need >> not forget that NetRexx started as a multi-language compiler >> engine (this explains the 'babel' references all over the >> sourcecode) and we know some deep thought has gone into this. > Indeed (the prefix in the name of the various classes is intended to indicate > those parts that are 'generic' -- apply to all languages -- and those that are > 'language-specific' [e.g., NetRexx]). The runtime was/is intended to underpin > all of the above (and of course be unnecessary for 'binary' programs). > > I strongly support efforts to make more automatic conversion between the Rexx > (as a string) and the String (and related) datatypes. I was cautious about > those because it was not clear how the String class would evolve and there are > also some method naming conflicts (substring is very different, for example). > With the benefit of a more stable Java and hindsight, a better integration of > these must be possible. > >> Personally, I am not opposed to polluting NetRexx with Java >> notions as long as the separation is clear. We could define >> an interface for the existing Rexx class, and add support for >> other things by adding another interface to the concrete >> type. When we look at the categories in Mike's previous >> email, we should actionally re-package the Runtime into pure >> NetRexx and Java-binary interfaces. So, I do agree with both >> views, and I think we should move forward- that is the only >> useful direction. > The Collections discussion is an interesting one. NetRexx (as a language) > really only has one kind of collection -- indexed strings -- and from experience > that's as about as far as the 'everyday programmer' wants to go. But there is > so much more that can be done; I'm just suggesting that going outside the > 'simple strings' paradigm is missing quite a lot of the point of Rexx. Much > better to have specialist collections, lists, and the like as purpose-designed > classes or (Rexx-aware subclasses) of the platform collections rather than > accreting ad hoc methods or constructors onto the 'primitive' Rexx datatype. > >>> Java is not going away. Android has made sure of that in the last >>> year or two. Java is not just a niche language for server >>> apps now but >>> a mainstream end-user application framework that is threatening to >>> blow away everything else. > (I said the same in an earlier post.) > >>> To be both blunt and honest - I >>> don't give a damn about some theoretical NetRexx >>> independent of Java. > But it is that separation that keeps the design and syntax clean. It allows > other syntaxes to be swapped in if one wishes (Basic-like, Smalltalk-like, and > maybe even Perl-like if you really want that). And if it allows that then one > can be fairly certain that the overall design is clean. Constructs and add-ons > that cross that boundary constrain the language to just one platform. And we > all know that [almost all] platforms have shorter lives than languages... > >>> I do wonder though if we will attract many new users from the Java >>> ranks in the current state of things. > That has been a valid question since 1997/2000 :-). At that time NetRexx had > features that Java did not have (still true now, of course) -- yet did not > attract as many users as expected. Sadly, there are few polyglot programmers; > most learn one programming language to begin with and are then forever trapped > in that 'culture'. > > 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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by billfen
... and that is, *exactly*, the reason why my *personal thinking* is the
we shall need some new classe, at all: Text -- for Text Strings Number -- for (Integer) numbers (of any size) Numeric -- for Decimal Numbers, with a decimal part, of any Size Logical -- for Logicals (booleans) Stem -- for Indexed Strings Rexx shall be *the superclass*, functioning right now, but I do personally *think* that the hughe Rexx Class (as well as the storage needed for any *Rexx* variable, can be then reduced! As I do see from mike's code, he *did have* a RexxNum class before, and did then *merge it* into Rexx! *Not* allowing, in the Language, do define an *Indexed Strin* (formerly called a Stem in classix Rexx) per se, does also imply that totally unexpected RUN-Time errors ashall occur, and also *do imply* that you do *not* see any difference (in the DECLARATION of a Property, for instance), whether a *Rexx* variable is an ordinary Text String, or an Indexed String! Any Language which will need a *Comment* (or *Note*, to specify that this is now an *Indexed String* (formerly called Stem) is *not really HUMAN* ... Sorry to say this again, Thomas. (at least, this my position is again NetRexx related) Consider it, therefore, please as a Contribution and *not* as an *unwanted* discussion point! PS: And, in HUMAN Thinking: 12 should be NOT equivalent to "12" When we do have *Types* (Classes) in NetRexx, we shall *continue* to use *established notations*! Otherwise: Confusion for Programming Beginners! ============================================================================ ========================================================================i Am 22.11.2012 02:20, schrieb Bill Fenlason: > 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/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by billfen
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/ |
|
|
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/ |
|
|
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/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |