What am I missing?
Locked
12
12
 
|
Hi,
117 +++ InRecord = InRecord.left(Length -1) +++ ^^^^ +++ Error: The method 'left(netrexx.lang.Rexx)' cannot be found in class 'java.lang.String' or a superclass 1. What am I missing, and import? Something in the classpath? Or is the Red Book out of date on the Java classes, in which case, is there a more up to date guide/tutorial? 2. Is there a way of returning a file object from a function (function only seems to return a Rexx object)? Thanks. Best regards, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Connor 1-5 inch.gif (1K) |
|
> Hi,
> > 117 +++ InRecord = InRecord.left(Length -1) > +++ ^^^^ > +++ Error: The method 'left(netrexx.lang.Rexx)' cannot > be found in class 'java.lang.String' or a superclass InRecord must be of type String and you need it to be of type Rexx. Best done at the time you create InRecord, but a quick fix is: NiceRecord = Rexx InRecord -- convert it to type Rexx NiceRecord = NiceRecord.left(Length - 1) etc. A good change for the OONetRexx would be for the compiler to do this automatically .. a couple of decisions to be made, there (but doable). I didn't make that one automatically back then because machines were a *lot* slower 13 years ago! Now it would be a good call. Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by FreeFall
"Rexx" functions don't work directly on Java Strings. Try it this way:
InRecord = Rexx(InRecord).left(Length -1).toString To return a "File" object from a method do this: --------------------------------------------------- method returnaFile returns File x=File("some.file") return x --------------------------------------------------- HTH -- Kermit Connor Birch wrote: Hi, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Mike Cowlishaw
Thanks Mike,
Rexx has that great characteristic of being non-bureaucratic, and allowing one to deal with concrete entities (rather than C's tangle of pointers). This has enormous benefits; allowing better quality programs to be written faster. Much of this seems to be negated in NetRexx+Java due to the abstract nature of java classes and the way they pile on top of one another. We can't simply use a ReadRecord method of a file (which would be ideal), we first have to create an object for the file (this out to be transparent), then have to create a stream object and read from that file. While there may be practical reasons for this, I think it would be nice if NetRexx insulated the programmer from this trivia (back to the original Rexx concept, make it easier for the programmer at the expense of the compiler/runtime system). Is there any chance that NetRexx will move further to rexxify working with objects, eg by defining more rexx objects that work seamlessly with each other? Connor. On 26 Feb 2010, at 20:53, Mike Cowlishaw wrote: >> Hi, >> >> 117 +++ InRecord = InRecord.left(Length -1) >> +++ ^^^^ >> +++ Error: The method 'left(netrexx.lang.Rexx)' cannot >> be found in class 'java.lang.String' or a superclass > > InRecord must be of type String and you need it to be of type Rexx. > Best > done at the time you create InRecord, but a quick fix is: > > NiceRecord = Rexx InRecord -- convert it to type Rexx > NiceRecord = NiceRecord.left(Length - 1) > > etc. > > A good change for the OONetRexx would be for the compiler to do this > automatically .. a couple of decisions to be made, there (but > doable). I > didn't make that one automatically back then because machines were a > *lot* > slower 13 years ago! Now it would be a good call. > > Mike > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Kermit Kiser
Hello Kermit & all,
you might also (when you like) use the Rexx2Nrx.RexxFile functions as currently documented at www.Rexx2Nrx.com. I would like to note, taht, after some very tesious tests, I did implement those by my own to give some 50% - 70% better performance than Object Rexx File I/O at those times. You will have to look at www.Rexx2Nrx.com/Run-Time docu (on the left hand side) Kind regards, Tom. ======================================================================= Kermit Kiser schrieb: > "Rexx" functions don't work directly on Java Strings. Try it this way: > > InRecord = Rexx(InRecord).left(Length -1).toString > > To return a "File" object from a method do this: > --------------------------------------------------- > method returnaFile returns File > > x=File("some.file") > > return x > --------------------------------------------------- > > HTH > -- Kermit > > > Connor Birch wrote: >> Hi, >> >> 117 +++ InRecord = InRecord.left(Length -1) >> +++ ^^^^ >> +++ Error: The method 'left(netrexx.lang.Rexx)' cannot be found >> in class 'java.lang.String' or a superclass >> >> 1. What am I missing, and import? Something in the classpath? Or >> is the Red Book out of date on the Java classes, in which case, is >> there a more up to date guide/tutorial? >> >> 2. Is there a way of returning a file object from a function >> (function only seems to return a Rexx object)? >> >> Thanks. >> >> Best regards, >> >> >> ------------------------------------------------------------------------ >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by FreeFall
Hi Connor,
please have a look at www.Rexx2Nrx.com -- Run-Time Docu -- RexxFile etc. Maybe those methods do help a bit.... Thomas Schneider. www.Rexx2Nrx.com www.db-123.com ==================================================================== Connor Birch schrieb: > Thanks Mike, > > Rexx has that great characteristic of being non-bureaucratic, and > allowing one to deal with concrete entities (rather than C's tangle of > pointers). This has enormous benefits; allowing better quality > programs to be written faster. > > Much of this seems to be negated in NetRexx+Java due to the abstract > nature of java classes and the way they pile on top of one another. > We can't simply use a ReadRecord method of a file (which would be > ideal), we first have to create an object for the file (this out to be > transparent), then have to create a stream object and read from that > file. While there may be practical reasons for this, I think it > would be nice if NetRexx insulated the programmer from this trivia > (back to the original Rexx concept, make it easier for the programmer > at the expense of the compiler/runtime system). > > Is there any chance that NetRexx will move further to rexxify working > with objects, eg by defining more rexx objects that work seamlessly > with each other? > > Connor. > > > > On 26 Feb 2010, at 20:53, Mike Cowlishaw wrote: > >>> Hi, >>> >>> 117 +++ InRecord = InRecord.left(Length -1) >>> +++ ^^^^ >>> +++ Error: The method 'left(netrexx.lang.Rexx)' cannot >>> be found in class 'java.lang.String' or a superclass >> >> InRecord must be of type String and you need it to be of type Rexx. >> Best >> done at the time you create InRecord, but a quick fix is: >> >> NiceRecord = Rexx InRecord -- convert it to type Rexx >> NiceRecord = NiceRecord.left(Length - 1) >> >> etc. >> >> A good change for the OONetRexx would be for the compiler to do this >> automatically .. a couple of decisions to be made, there (but >> doable). I >> didn't make that one automatically back then because machines were a >> *lot* >> slower 13 years ago! Now it would be a good call. >> >> Mike >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by FreeFall
> Thanks Mike, > > Rexx has that great characteristic of being non-bureaucratic, > and allowing one to deal with concrete entities (rather than > C's tangle of > pointers). This has enormous benefits; allowing better quality > programs to be written faster. > > Much of this seems to be negated in NetRexx+Java due to the abstract > nature of java classes and the way they pile on top of one > another. Yes, this is largely inherent in the OO model of Java. > We can't simply use a ReadRecord method of a file (which > would be ideal), we first have to create an object for the > file (this out to be transparent), then have to create a > stream object and read from that > file. While there may be practical reasons for this, I think it > would be nice if NetRexx insulated the programmer from this > trivia (back to the original Rexx concept, make it easier for > the programmer at the expense of the compiler/runtime system). Many people have said they miss linein/charin etc. -- there's a good argument for making a RexxFile kind of object part of the 'standard runtime'. Or even re-introducing/permitting static functions perhaps, where if the programmer writes: x=foo(bar, 2, 3) this would be treated as: x=bar.foo(2, 3) Would need some thought. > Is there any chance that NetRexx will move further to rexxify > working with objects, eg by defining more rexx objects that > work seamlessly with each other? That's up to the new owners of NetRexx :-). Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
El 27/02/2010 8:53, Mike Cowlishaw escribió: We can't simply use a ReadRecord method of a file (which > would be ideal), we first have to create an object for the > file (this out to be transparent), then have to create a > stream object and read from that > file. While there may be practical reasons for this, I think it > would be nice if NetRexx insulated the programmer from this > trivia (back to the original Rexx concept, make it easier for > the programmer at the expense of the compiler/runtime system).Many people have said they miss linein/charin etc. -- there's a good argument for making a RexxFile kind of object part of the 'standard runtime'. I would strongly advocate in making these kind of things part of a 'standard library' rather than the runtime. For the case in point RXFile is available at http://webspace.webring.com/people/ju/um_3777/. Unfortunately it's not open source although it is freeware. An excerpt of its documentation TOC follows: 2.3.2 ** RXFile constructors in NetRexx ** 2.3.3 ** The STREAM method ** 2.3.4 ** The CHARS method ** 2.3.5 ** The LINES method ** 2.3.6 ** The CHARIN method ** 2.3.7 ** The LINEIN method ** 2.3.8 ** The CHAROUT method ** 2.3.9 ** The LINEOUT method ** 2.3.10 ** The DELETE method ** 2.3.11 ** The RENAME method ** 2.3.12 ** The MKDIR method ** 2.3.13 ** The MKDIRS method ** 2.3.14 ** The PROPERTIES method ** 2.3.15 ** The FILETREE method ** 2.3.16 ** The SETPARMS method ** 2.3.17 ** The GETPARMS method ** 2.3.18 ** The ADDCURSOR method ** 2.3.19 ** The GETCURSOR method ** 2.3.20 ** The DELCURSOR method ** 2.3.21 ** The DELALLCURSORS method ** 2.3.22 ** The ATTACHTOINPUTSTREAM method ** 2.3.23 ** The ATTACHTOOUTPUTSTREAM method ** 2.3.24 ** The COPY method ** 2.3.25 ** The MOVE method ** 2.3.26 ** The VERSION method ** Using this you can even work with any kind of iostreams (files, network sockets, etc) using the familiar REXX interfaces (CHARIN, LINEOUT, et al). IMHO having a small runtime while taking advantage of java´s massive one is one of NetRexx strong points. I'm sure most of the missed REXX features can readily be implemented in NetRexx/Java. RXFile can be used just by including an import instruction; even without that in many cases in fact... I envision the NetRexx user community building a common repository of such 'tool' classes supporting all kinds of development in our language of choice. To be honest, I don't fully understand why this is not happening right now. It seems everybody is waiting for NetRexx becoming OOS. For the most part this kind of improvements can be done without access to the compiler sources. > Is there any chance that NetRexx will move further to rexxify > working with objects, eg by defining more rexx objects that > work seamlessly with each other? Well, I gess I've already made clear that if I'm ever going to have any influence over NetRexx future evolution, I wont be on the "lets port classic REXX to the Java!" camp :-) Kind regards, David _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
David Requena wrote:
Maybe I'm also missing the point, but NetRexx is built on Java, and Java brings a boatload of libraries for every conceivable application, including "RxFile" type operations. Why reinvent the wheel? Just curious. Tom. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by David Requena
> I would strongly advocate in
making these kind of things part of a
> 'standard library' rather than the runtime. Not quite sure how these are different: 'standard library'
means "available to all programs as required". 'runtime' is the
same? Except possibly packaging ... the 'runtime' in
NetRexx was the one .jar .. but even that would have better have been
loaded by Java a class at a time when needed, but I don't think that was
an option then.
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Tom Maynard
Tom,
That is indeed my point. NetRexx already has a behemoth of a library/runtime. If someone (not me) misses something from REXX as the case in point, well, that can be done without touching the language itself, or its runtime. In the example I was discussing you get better functionality than original REXX's as you might use LINEIN to read from e.g. an httprequest in a servlet, not just with files. --- Saludos / Kind regards. David Requena El 03/03/2010 15:23, Tom Maynard escribió: David Requena wrote:Maybe I'm also missing the point, but NetRexx is built on Java, and Java brings a boatload of libraries for every conceivable application, including "RxFile" type operations. Why reinvent the wheel? _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Mike Cowlishaw
El 03/03/2010 15:40, Mike Cowlishaw escribió:
Agreed that was a bad choice of words. I put '' around 'standard library' to convey that I didn't meant the term in the conventional meaning (which I agree is quite equivalent to runtime). Lets try again :-) I think if there is high demand for, say, a RexxFile object, then this should be: - Implemented as a class. - Available to anyone from some central repository (www.netrexx.org/std-components ??) - People interested can include these in their projects. The current (lean and mean) NetRexx runtime supports functionality integral to the language (decimal arithmetic, Rexx type,...). File access functions are an 'utility' interface possibly only of interest to programmers coming from classic REXX. Everyone else would be just paying a toll, with a bigger NetRexxR.jar file to distribute, basically for nothing in exchange. I never saw NetRexx as an attempt to port classic REXX to the java virtual machine but as a language in itself. Maybe I've been wrong all the time here. --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Quote:
I think if
there is high demand for, say, a RexxFile object, then this should be:
- Implemented as a class. - Available to anyone from some central repository (www.netrexx.org/std-components ??) - People interested can include these in their projects. The current (lean and mean) NetRexx runtime supports functionality integral to the language (decimal arithmetic, Rexx type,...). File access functions are an 'utility' interface possibly only of interest to programmers coming from classic REXX. Everyone else would be just paying a toll, with a bigger NetRexxR.jar file to distribute, basically for nothing in exchange. I never saw NetRexx as an attempt to port classic REXX to the java virtual machine but as a language in itself. Maybe I've been wrong all the time here. Not wrong :-). I think we are 'in violent
agreement', here :-))
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by David Requena
Hello Mike, David, Rene, & al,
I totally DO agree on this conversation. RexxFile is a class (currently in package Rexx2Nrx.Rexx2RT, class RexxFile). What I have been proposing to Rene was: -- choose a proper 'new package name' (I did choose package Rey.RT, for the minute, and class name ReyFile, by the way... -- have those additional Functionality as part of the open source NetRexx release ... just a proposal, from my side. But as I am now trying to finish my Rey Compiler Project, I *do need to have* a *decision* which naming conventions shall be used !!! ;-) Agreed ? Tom. ========================================================== David Requena schrieb: > > El 03/03/2010 15:40, Mike Cowlishaw escribió: >> > I would strongly advocate in making these kind of things part of a >> > 'standard library' rather than the runtime. >> >> Not quite sure how these are different: 'standard library' >> means "available to all programs as required". 'runtime' is the >> same? Except possibly packaging ... the 'runtime' in NetRexx was >> the one .jar .. but even that would have better have been loaded by >> Java a class at a time when needed, but I don't think that was an >> option then. >> > > Agreed that was a bad choice of words. I put '' around 'standard > library' to convey > that I didn't meant the term in the conventional meaning (which I > agree is quite > equivalent to runtime). > > Lets try again :-) > > I think if there is high demand for, say, a RexxFile object, then this > should be: > > - Implemented as a class. > - Available to anyone from some central repository > (www.netrexx.org/std-components ??) > - People interested can include these in their projects. > > The current (lean and mean) NetRexx runtime supports functionality > integral > to the language (decimal arithmetic, Rexx type,...). > > File access functions are an 'utility' interface possibly only of > interest to programmers > coming from classic REXX. Everyone else would be just paying a toll, > with a bigger > NetRexxR.jar file to distribute, basically for nothing in exchange. > > I never saw NetRexx as an attempt to port classic REXX to the java > virtual machine > but as a language in itself. Maybe I've been wrong all the time here. > > --- > Saludos / Kind regards. > David Requena > > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by David Requena
Do not yet know ahat I would have to change to handle URL's in RexxFile
(or ReyFile, as it is called in my development version *at the current minute*). What I am interested in is that we do (*in concert*) maintain one, and only one, version. ... and I did invest a lot of time to implement the missing links between Mike's The Rexx Language *and* The NetRexx Language books (as far as I can, of course...) Tom. =========================================================== David Requena schrieb: > Tom, > > That is indeed my point. > > NetRexx already has a behemoth of a library/runtime. If someone (not me) > misses something from REXX as the case in point, well, that can be done > without touching the language itself, or its runtime. > > In the example I was discussing you get better functionality than original > REXX's as you might use LINEIN to read from e.g. an httprequest in a > servlet, > not just with files. > > > --- > Saludos / Kind regards. > David Requena > > El 03/03/2010 15:23, Tom Maynard escribió: >> David Requena wrote: >>> >>> I would strongly advocate in making these kind of things part of a >>> 'standard library' rather than the runtime. >> Maybe I'm also missing the point, but NetRexx is built on Java, and >> Java brings a boatload of libraries for every conceivable >> application, including "RxFile" type operations. Why reinvent the wheel? >> >> Just curious. >> Tom. >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by Thomas.Schneider.Wien
> choose a proper 'new package name' (I did choose package
> Rey.RT, for the minute, and class name ReyFile, by the way... > I *do need to have* > a *decision* which naming conventions shall be used !!! ;-) The naming of packages in Java space is nothing to do with NetRexx .. it is described in the Java Language Specification -- section 6.8.1 (Package Names) in the Java Language Specification, which can now be found here: http://java.sun.com/docs/books/jls/third_edition/html/names.html#73307 (Note: in the first edition the book said that the top-level domain should be uppercase --- for example COM --- whereas in practice convention forced that to be lowercase if you want things to work on all platforms, and that is now what's in the text linked above.) So if you have a domain called (say) rey.org then it would be sensible to call your packages org.rey.whatever Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hi Mike,
thanks for the advise and the link! :-) Have a nice weekend! Tom. ============================================================ Mike Cowlishaw schrieb: >> choose a proper 'new package name' (I did choose package >> Rey.RT, for the minute, and class name ReyFile, by the way... >> I *do need to have* >> a *decision* which naming conventions shall be used !!! ;-) >> > > The naming of packages in Java space is nothing to do with NetRexx .. it > is described in the Java Language Specification -- section 6.8.1 (Package > Names) in the Java Language Specification, which can now be found here: > http://java.sun.com/docs/books/jls/third_edition/html/names.html#73307 > > (Note: in the first edition the book said that the top-level domain should > be uppercase --- for example COM --- whereas in practice convention forced > that to be lowercase if you want things to work on all platforms, and that > is now what's in the text linked above.) > > So if you have a domain called (say) rey.org then it would be sensible to > call your packages org.rey.whatever > > Mike > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
Static functions (was What am I missing?)
|
|
In reply to this post by Mike Cowlishaw
El 27/02/2010 8:53, Mike Cowlishaw escribió: Many people have said they miss linein/charin etc. -- there's a good argument for making a RexxFile kind of object part of the 'standard runtime'. Or even re-introducing/permitting static functions perhaps, where if the programmer writes: x=foo(bar, 2, 3) this would be treated as: x=bar.foo(2, 3) Would need some thought. Mike, Thinking a bit about this... wouldn't that very same thing be accomplished by putting a 'uses Bar' construct in the signature of any class calling foo(bar, 2, 3)? 'uses' keyword aside, I'm not sure how the so-called static functions would be found by the language processor. For starters there may exist many definitions of foo(byte, byte) with no clear hint on precedence. Another potential problem I see is: how would the language processor determine which method to call when both foo(Bar, byte, byte) and foo(byte, byte) static methods are defined at class Bar? This stuff is a little mind twisting and I'm a bit dense this morning but the 're-introducing' term in your note suggests you already gave some thought to these matters. Thanks for your thoughts! --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
RE: Static functions (was What am I missing?)
|
|
Yes, agree there are some problems (and Uses is a bit
strange). Hence the "Would need some
thought." in my post... :-)
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Static functions (was What am I missing?)
|
|
May I add my 2 cents, please:
1.) Rexx2Nrx (*and* ReyC) *do* translate the 'function oriented notation' to the 'object oriented oerientation' for all 'classic Rexx' BUILTIN functions. I (personally) do use a leading hash-sign in the 'function definition template' in the 'Rexx.builtin' file to denote, which parameter is the 'subject' (object) of the function in question. 2.) Within ReyC, I'm currently trying to do the same for NetRexx programs as well. But this is still an experimental feature, as I do not want to change Mike's language spec without agreement of the community. Thomas Schneider. ============================================================ static Functions Mike Cowlishaw schrieb: > Yes, agree there are some problems (and Uses is a bit strange). Hence > the "Would need some thought." in my post... :-) > > Mike > > ------------------------------------------------------------------------ > *From:* [hidden email] > [mailto:[hidden email]] *On Behalf Of *David > Requena > *Sent:* 18 March 2010 11:31 > *To:* IBM Netrexx > *Subject:* [Ibm-netrexx] Static functions (was What am I missing?) > > > El 27/02/2010 8:53, Mike Cowlishaw escribió: >> Many people have said they miss linein/charin etc. -- there's a good >> argument for making a RexxFile kind of object part of the 'standard >> runtime'. Or even re-introducing/permitting static functions perhaps, where >> if the programmer writes: >> >> x=foo(bar, 2, 3) >> >> this would be treated as: >> >> x=bar.foo(2, 3) >> >> Would need some thought. >> > > Mike, > > Thinking a bit about this... wouldn't that very same thing > be accomplished by putting a 'uses Bar' construct in the > signature of any class calling foo(bar, 2, 3)? > > 'uses' keyword aside, I'm not sure how the so-called static > functions would be found by the language processor. > > For starters there may exist many definitions of foo(byte, byte) > with no clear hint on precedence. > > Another potential problem I see is: how would the language > processor determine which method to call when both foo(Bar, byte, > byte) > and foo(byte, byte) static methods are defined at class Bar? > > This stuff is a little mind twisting and I'm a bit dense > this morning but the 're-introducing' term in your note > suggests you already gave some thought to these matters. > > Thanks for your thoughts! > > --- > Saludos / Kind regards. > David Requena > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |