Learning Java Objects
Locked
123
123
 
|
The prospect of learning Java Objects scares me. I imagine that the more of it one learns, the more one detests it, and the more one discovers how much more they have to learn. I imagine that it is a pit down which man months can be poured. Am I right?
I fear that my life is not long enough to fit in that as well as everything else. Can I really avoid learning Java, ie are there enough rexxish objects in existence that I can create screen dialogues (pull down lists etc etc) without having to touch Java Objects? If I do have to learn Java Objects, what is the least painful path? Thanks, Connor. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Can't answer that comprehensively, but here's an idea or two.
I don't think you need to learn much Java to get a great deal of control over Java. If you've written any NetRexx you've written Java, but NetRexx conceals this most skillfully (in many cases, a Java programmer might not recognize that Java technology underlays NetRexx). You don't have to learn Java syntax (basically C, ugh) at all, unless you expect to read Java programs. But you can do with NetRexx anything a Java programmer can because you have the ability to call the Java Class Library, which contains 200+ packages (ie, areas of interest) and 2700+ classes, and GOK how many methods (functions) acting on those classes. If you dig in a bit, I think the more you learn, the more your respect will grow, because Java's starting point was a clear eyed study of what's wrong with prior Object Oriented languages (Smalltalk, C++ principally). When I made the change from C to Java, it was like night and day. Nobody used a debugger, although we were give JBuilder, because errors occurring at runtime in other languages are caught at compile time in Java (and NetRexx). As a result debugging was done with print statements, because you were debugging your design, not some bizarre error induced by a lunatic language. Lest I sound like a Java stockholder, the minute I was in a position to choose my own language, I switched to NetRexx (which I had played with, but could not use at my company) and never wrote another Java program. It's not Java programming you need so much, but a handle on Java terminology and tools. The most important tool to understand is javadoc, because it gives you browser access to the entire API. But you need some words before that will make sense. You might as well get it from the experts; try nosing around http://download.oracle.com/javase/tutorial/. On Mon, Oct 4, 2010 at 2:57 PM, Connor Birch <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
On 10/4/2010 3:27 PM, George Hovey wrote:
But you can do with NetRexx anything a Java programmer can because you have the ability to call the Java Class Library, which contains 200+ packages (ie, areas of interest) and 2700+ classes, and GOK how many methods (functions) acting on those classes.I think this is exactly the fear mentioned by the OP: > The prospect of learning Java Objects scares me. And then he gives a specific case regarding creating a GUI application ... certainly not something you can do without poring over tons of JavaDoc, and plenty of trial and error (although tutorials abound). There exist GUI builders for Java (NetBeans has one, e.g.) but I haven't figured out how to rewire them to use with NetRexx -- althoughI haven't spent a lot of time trying. NetRexx with "native" GUI libraries would become (IMO) practically the ideal language. Tom (from breezy Chicago). _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
GUIs certainly are a tough case. But if memory serves, that is exactly the application that brought OO out of the lab and into everyday use in the '90s. I've never heard anyone say that GUI programming can reasonably be carried out with procedural languages -- it's just too complex (I saw my company doing it in C in 1996; it would take more than a week to turn out a dialog of medium complexity under OS/2). Wouldn't a "native" GUI library be just as complex as Java's? And Java is way ahead of Microsoft's C++ approach.
As an alternative to poring or JavaDocs, try "Java Swing" (O'Reilly). This really delivers the goods. Hope David Requena weighs in on this - I think he is pretty GUI aware.
On Mon, Oct 4, 2010 at 6:08 PM, Tom Maynard <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
I agree that it would be pointless to reinvent the Java libraries. The
whole point of a library is that you don't have to write the code or
know exactly how it works - you only need to know what it does and how
to invoke it. The real problem seems to be a documentation issue.
Perhaps we need a translator program to convert Java documentation into
NetRexx type documentation?
As for GUI programming, it is not too bad once you get past the initial learning curve. Here is a crude sample GUI program that I wrote for Thomas early this year to help with that hump: ---------------------------------- NetRexx GUI sample code --------------------------------------- import javax.swing. class guisample implements ActionListener -- ActionListener interface lets the GUI objects talk to the program code properties static frame=JFrame -- holder for a GUI window method main(sa=String[]) static frame=JFrame("Sample GUI window") -- create a GUI window frame frame.setSize(400,100) -- give the window some space on the screen panel=JPanel() -- create a panel to hold some GUI objects frame.add(panel) -- put the panel in the window frame textfield=JTextField("Some default text here") -- create a spot for some text panel.add(textfield) -- add the text field to the panel button=JButton("OK") -- create a button to click button.addActionListener(guisample()) -- attach some code (an instance of this class) to watch the button panel.add(button) -- put the button in the panel frame.show -- display the GUI window on the screen loop while frame\=null;end -- wait for the GUI window to do something say textfield.getText -- show the text field contents method actionPerformed(e=ActionEvent) -- this is the code that listens to the button frame.dispose -- clear the GUI window frame from screen and memory frame=null -- erase the pointer to stop the main program ------------------------------------------------------------------------------------------------------------- On 10/4/2010 5:22 PM, George Hovey wrote: GUIs certainly are a tough case. But if memory serves, that is exactly the application that brought OO out of the lab and into everyday use in the '90s. I've never heard anyone say that GUI programming can reasonably be carried out with procedural languages -- it's just too complex (I saw my company doing it in C in 1996; it would take more than a week to turn out a dialog of medium complexity under OS/2). Wouldn't a "native" GUI library be just as complex as Java's? And Java is way ahead of Microsoft's C++ approach. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by FreeFall
Connor,
I'm sorry, I didn't address your interest in GUIs. The NetRexx distribution comes with a sample GUI program, BUTTONS, under directory BROWSE that illustrates some of the ins and outs of GUI programming. I doubt that MFC writes unnecessarily complex programs, but even so I do not find the operation of this program obvious (I have only limited GUI experience). He is using Java graphics classes. A few years ago I had to turn out a NetRexx GUI program. To do it I had to understand basic GUI issues and a fairly complex class that dealt with tables (JTABLE). Starting from zero I was able to get it done in two weeks with the help of "Java Swing" (O'Reilly). I also just picked up on your question about "rexxish" objects. AFAIK, the only NetRexx object is the Rexx class itself. On Sep 3, MFC wrote in answer to a query: "There's no date function in NetRexx (ditto I/O) because the assumption was that people would use the existing Java classes for that. And they were a lot of work, beyond my resources (me)." That is, MFC fully expects users to rely on the Java class library. He seems to open the door to changing this if sufficient manpower were available, but I don't know what he has in mind.Re complexity, I remember being simply overwhelmed as I tried to grasp the many issues in Java, at a time when the documentation was greatly inferior to today's. I, too, am at an age where I think carefully about committing myself to lengthy courses of action. If you decide to delve into GUIs, say, the situation is not as bad as it sounds. The vast majority of Java packages deal with issues -- eg, cryptography, remote method invocation and other arcane things -- that you can just ignore. I would start with "Java Swing" and read only parts that seem focused on your goal, trying to avoid getting side tracked. I would also equip myself with Ian F. Darwin's "Java Cookbook" (O'Reilly). When you think you must investigate some side issue, try this book first. It consists of many short, focused articles that bring you up to speed on some Java issue. I have been amazed at the number of times I have found just what I needed. On Mon, Oct 4, 2010 at 2:57 PM, Connor Birch <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
The http://download.oracle.com/javase/tutorial/ has a link to itself. . .
??? Bob Hamilton On Mon, Oct 4, 2010 at 8:26 PM, George Hovey <[hidden email]> wrote: Connor, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by George Hovey-2
The page at http://download.oracle.com/javase/tutorial/ has a link to itself. . .
??? Bob Hamilton On Mon, Oct 4, 2010 at 3:27 PM, George Hovey <[hidden email]> wrote: Can't answer that comprehensively, but here's an idea or two. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by George Hovey-2
It sounds as I feared. Ie the advocates are those who have slogged through it already (it seems easier once you've done it). The less painful routes require learning other things, and books inches thick are recommended.
I have the book Java Cookbook which I purchased some months ago (over 800 pages). My book-mark is at page 43, I no longer know why, did I give up reading it at that point? Or was this the first of the potentially many pages I might need? Whichever it is, it is a daunting prospect. If I earned my living by programming, the investment in time to learn Java's objects could be justified. But I don't have two spare weeks. Even if I did, there are others things to learn that would also make a claim on those weeks. Two weeks is too long to get a simple GUI running, something is wrong either with the structure of Java's Objects, or with the tuition materials, if it takes that long. To 'add insult to injury', I imagine that those two weeks are also full of frustration. One important thing that attracts me to rexx is the speed with which I should be able to write programs; it sounds like java's objects, although being the great portability feature and strength of NetRexx, is currently also the language's Achilles heel. Maybe, the thing that could transform NetRexx into a mainstream language is not additional features like Increment, but a set of NetRexx objects that insulates the programmer from the 2% or java objects used 98% of the time (eg file processing and gui processing)? Or, perhaps a straight forward guide for NetRexx programmers on how to write GUI's that contains not a single line of java code? Regards, Connor. On 5 Oct 2010, at 02:26, George Hovey wrote: Connor, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Robert L Hamilton
Bob,
I fell into the same trap with the same reaction; I should have warned you. Continue further down that page to "Trails Covering the Basics" and you'll find these, all contain a lot of meat (I wish I'd had this when I started struggling with Java in '98): Getting Started — An introduction to Java technology and lessons on installing Java development software and using it to create a simple program. These are under Getting Started:
The Java Technology Phenomenon
Provides an overview of Java technology as a whole.
It discusses both the Java programming language
and platform, providing a broad overview of what this technology can do
and how it will make your life easier.
Essential Java Classes — Lessons on exceptions, basic input/output, concurrency, regular expressions, and the platform environment. Collections — Lessons on using and extending the Java Collections Framework. SUGGEST SKIPPING THIS. Swing — An introduction to the Swing GUI toolkit, with an overview of features and a visual catalog of components. See below for a more comprehensive tutorial on Swing. On Tue, Oct 5, 2010 at 5:07 AM, Robert Hamilton <[hidden email]> wrote: The page at http://download.oracle.com/javase/tutorial/ has a link to itself. . . _______________________________________________ Ibm-netrexx mailing list [hidden email] |
The "Hello World!" Application|
|
In reply to this post by George Hovey-2
On Mon, Oct 4, 2010 at 9:22 PM, George Hovey <[hidden email]> wrote:
> GUIs certainly are a tough case. But if memory serves, that is exactly the > application that brought OO out of the lab and into everyday use in the > '90s. I've never heard anyone say that GUI programming can reasonably be > carried out with procedural languages Oh yes it was possible... CA-Realizer, Computer Associates´ Visual Basic killer. I used it under IBM´s OS/2. It was like having today´s Netbeans and GUI builder with the ability to write procedural code. I loved it. Sadly after the win95 epidemic, they dropped their os/2 port -CA Realizer 3.0 was in beta and os/2 beta testers were already being requested- (i assume some money from Microsoft was involved as around the same time frame, CA signed some estrategic agreement with MS to integrate CA´s system management with Windows NT....). Then there was IBM VisualAge for Basic. It was like CA-Realizer but using 4x the memory and with apps running several orders of magnitude slower. I remember being told that all of VisualAge products used some smalltalk runtime, and that the death of all IBM VisualAge products was due to this fact. (Another incredible management decision by IBM). Then for years I´ve chased windmills trying to find: 1. Anyone who worked at CA-Realizer 2. Anyone who worked at IBM VA Basic 3. Trying to convince Sybase (which opensourced the Watcom C++ compiler as OpenWatcom) to open source Watcom VX-Rexx Needless to say, I failed miserably at all of them. So these days basically I throw random rocks in Sun´s general direction trying to get the attention of anybody who would listen, saying that resurrecting Sun´s Project Semplice would be a good idea. Prject Semplice was one Sun development, presented at JavaOne2006 (and it was working!), where you basically wrote Basic code in Netbeans, and got compiled Java bytecode as a result. Inexplicably, Sun let one of its main engineers leave the firm in 2007, and he went to work in Google´s Davlik. Project Semplice was dead. Now, I´m not a compiler author, but wonder if completing the incomplete Project Semplice would be such rocket science. H*ck, Oracle even owned a Basic-like development tool at one point: Oracle PowerObjects... and OpenOffice contans "StarOffice Basic"... so from an intellectual property point I don´t think they´d need to pay MSFT a dime. Thoughts? Comments? Expletives? ;-) FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by George Hovey-2
El 05/10/2010 2:22, George Hovey escribió: Hope David Requena weighs in on this - I think he is pretty GUI aware. OK, George, I'll bite that bait :-) But instead of replying to several posts I'll try to summarize my views just here. This is not particularly addressed to you, George, but to anyone fearing the "java objects" thing. It is unclear to me if the original questions by Connor were addressed to 'learning java objects' in general or just to to GUI programming. There're good and bad news for the latter which I'll address in a follow up email. IMO the stumbling block when coming to object oriented programming from an structured or procedural background is precisely the mind shift required by OO. You need to start thinking in objects as opposed procedures, subroutines, functions, data structures an so. I'm told this can be difficult to achieve. In all honesty it wasn't for me. OO is all about a few very simple principles with fancy names specially designed to scare outsiders (polymorphism, encapsulation, information hiding, inheritance, abstraction, message passing, decoupling, ...). Believe me, this is very simple stuff. If your ever implemented and ADT in your procedural language of choice, you already have done 80% of the way! In short, don't bother to "learn java's objects" (or C++', Smalltalk's, Python's, or even NetRexx'). Just pick some tutorial on object orientation which plainly explains these OO concepts and you'll be prepared to tackle any OO language. At the end of the day it's just a matter of assessing how these languages' syntaxes support the basic OO concepts. Most languages do a pretty poor job out of this task but that is not the case of NetRexx :-) I would recommend http://en.wikipedia.org/wiki/Object_orientation as a gentle introduction to OO. Just read that article and you'll be amazed at how much LESS astonishing OO discussions in front of you become. Also NetRexx in particular allows for a gentle two phased approach to OO programming in which you don't do any OO coding but you just *USE* existing objects. That is NetRexx' scripting mode. /* An script using objects */ Say "This particular instant in time is:" Date().toString /* done! */ Yep! We didn't bother with classes, methods, properties or anything OO here. Just took advantage of a given Date object which offers a toString "function" returning a nicely formatted string. As a matter of fact you can leverage the whole java library (and literally thousands of freely available OSS ones) in this fashion; just by putting your run of the mill first argument to the front, putting in a dot and then the function (method!) at the end. Not bad! Maybe latter you might get interested in getting into OO, doing your own classes, extending the standard ones, etc. Or maybe not. In the meantime why not use the sheer power NetRexx puts at your finger tips?!! --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by FreeFall
El 05/10/2010 12:34, Connor Birch escribió: It sounds as I feared. Ie the advocates are those who have slogged through it already (it seems easier once you've done it). The less painful routes require learning other things, and books inches thick are recommended. See my previous post for a gentler path into OO without the burden of the syntax for a language you're not interested in (java's)
That kind of book I wouldn't recommend for getting into it. It's not teaching anything important about the broad picture. It's just putting some huge number of java recipes for some corner cases together. Worse, it's just java tips and tricks! Admittedly such a book is handy to have once you have a working knowledge of the basics. In many cases it gives you ready made components for the problem at hand.
When it comes to the java library, I think it's just a matter of overseeing what is available in there and how is it broken into different "functional domains" (packages). Then, when you need something in particular, you just look it up and use it. I don't think anyone is going to hold the whole 2700+ classes thing in his head! --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by David Requena
On 5 Oct 2010, at 12:47, David Requena wrote:
Okay, I don't have a problem wit the concepts, most of what you mentioned ought to be familiar stuff to anyone who has written well structured code. The only concept listed above that goes beyond 'normal' programming is inheritance. I once took a course in Objective C; learning the concepts was no problem. Making sense of the programming language was another issue entirely.
In short, is there a NetRexx Cookbook? Connor. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by FreeFall
I've commented on a number of your points below.
On a more general note, I am eager to interact with people like you who come upon NetRexx afresh because I think your experiences contain important clues to making NetRexx a success. My ideas are pretty formless but I hope they will firm up, at which point I will present them to the group, but here are a few fragments. I'd like to see NetRexx be a "big tent", ie accommodate programmers from a variety of backgrounds. It already has the machinery to "empower" this with the ability to write, at one extreme, what MFC calls a "low boilerplate" class that shows no trace of its Java parent and, at the other extreme, the equivalent of a full scale Object Oriented Java program in a language that is vastly more pleasant to use. But mentioning Java causes a big problem: it tends to set people rapidly back pedaling. I think it is essential not to "turn off" a potential convert and this means carefully managing his initial contact with NetRexx. Our "sales brochure" might say early on something like
"NetRexx is based internally on Java technology, BUT DON'T PANIC. It has been designed so that you can address it at several levels. You can write a "script" which manipulates operating system entities, eg files, issues commands, etc; or you can write a "procedural program", ie one consisting of traditional functions [add FUNCTION/SUBROUTINE as a synonym for METHOD, COMMON for PROPERTIES Static Private?] acting on data, neither of which betray any Java characteristics. Finally, you can write a program that exploits the full power of Java Technology using a simplified syntax." Re your idea of providing a tutorial for Java/GUI, I think that the Oracle link I mentioned to Bob might be appropriate. I would appreciate your looking at it and giving your reaction. We might prepare an annotated reading list -- books and internet links -- whose
validity is checked regularly to reduce the number of negative user
experiences. These could have user reviews in the manner of Amazon. That is, the "selling" of NetRexx should be taken as
seriously as its software development.Again, I apologize for sending you off to read 800 page books which I haven't read! One idea On Tue, Oct 5, 2010 at 6:34 AM, Connor Birch <[hidden email]> wrote:
Yes, though in a complex way; also an important strength.
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Fernando Cassia-2
Fascinating, but all news to me. I was in love with Watcom VX-Rexx!
On Tue, Oct 5, 2010 at 7:37 AM, Fernando Cassia <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Re: Learning Java Objects (The GUI affair)
|
|
In reply to this post by George Hovey-2
El 05/10/2010 2:22, George Hovey escribió: Hope David Requena weighs in on this - I think he is pretty GUI aware. While that might be true, I've to say it'd be more out of sheer stubbornness in tackling hard challenges than out of any practical matter :-) Non-trivial GUIs are not easy to make from NetRexx nor from java itself. FWIW the only reasonable way to do this is by taking advantage of the fact that java classes and NetRexx's own are the very same thing. So my advice is: do use NetBeans' wonderful point & click tools to make your GUI, compile it, and then drive it from your NetRexx program. Use your time to do more interesting things with NetRexx :-) I think René is also using this approach in his projects. See http://www.rexxla.org/events/2004/renej.pdf In general GUI programming is a hard domain in itself. It is in java, it is in windows, it was in OS/2, Linux,... you get the picture. That's why tools such as the ones mentioned by Fernando exist. IMHO GUI programming makes no good introduction to any language and/or platform. In the case of java platform the issue is exacerbated by the fact that its GUIs must work consistently across many underlying platforms with very different graphics systems, usability conventions, etc. In short, java's GUI framework (SWING) must be pretty generic. Java GUI programming is not only about object oriented programming. You must also have a good grasp about event driven programming, swing's particular threading model and and the model-view-controller design pattern. And that is just a start! Lets see these in a bit of detail. Lets also use Kermit's sample for illustration purposes: ---------------------------------- NetRexx GUI sample code --------------------------------------- import javax.swing. class guisample implements ActionListener -- ActionListener interface lets the GUI objects talk to the program code properties static frame=JFrame -- holder for a GUI window method main(sa=String[]) static frame=JFrame("Sample GUI window") -- create a GUI window frame frame.setSize(400,100) -- give the window some space on the screen panel=JPanel() -- create a panel to hold some GUI objects frame.add(panel) -- put the panel in the window frame textfield=JTextField("Some default text here") -- create a spot for some text panel.add(textfield) -- add the text field to the panel button=JButton("OK") -- create a button to click button.addActionListener(guisample()) -- attach some code (an instance of this class) to watch the button panel.add(button) -- put the button in the panel frame.show -- display the GUI window on the screen loop while frame\=null;end -- wait for the GUI window to do something say textfield.getText -- show the text field contents method actionPerformed(e=ActionEvent) -- this is the code that listens to the button frame.dispose -- clear the GUI window frame from screen and memory frame=null -- erase the pointer to stop the main program ------------------------------------------------------------------------------------------------------------- - Event driven programming. OK, your main(args=String[]) method gets called, some window gets painted on the screen and nothing else happens. In particular the flow of your program falls down the end of the function but your app does not terminate! It just sits there waiting for you to click some button, menu, etc. When you do so that actionPerformed(e=ActionEvent) function gets "magically" called. Who calls it? I'll be answering these questions in the threading model section. The point here is that under event driven programming you don't control your programs flow. Instead you create some graphics objects and let the system paint them on the screen. When some object is to be active, you register some listener object which will be called by the system behind the scenes when needed. That is what button.addActionListener() is doing in Kermit's code. If you want your app to terminate, you need to do so explicity like actionPerformed(e=ActionEvent) above. Nothing of this is very OO. It is in fact very similar to how you go about in in, say, Windows GUI programming. - Threading model. Why doesn't the program terminate when flow reaches the end of main? How actionPerformed() gets called? Whenever you create some GUI object the runtime starts in the background a so-called Event Dispatch Thread (EDT) which will keep running until you somehow tell it to quit. This is the thread which watches Kermit's button and calls actionPerformed() when needed. In this program calling frame.dispose causes all childs added to it to also be disposed. As there are no remaining GUI objects the EDT shuts itself down and the app finally terminates. Now look at the loop in red above. This is not needed at all; the program works exactly the same without it. It is in fact an error; it will just cause one of your CPU cores to go 100% CPU usage for just nothing. IOW, you don't need to keep your execution thread alive, the EDT will prevent the program to terminate. Another thing to be aware of is that most GUI components are not thread safe so they should only be modified from the EDT. But you don't want to call any long running function from the EDT as your application would freeze until it were finished running. This leads to scenarios involving several threads, calls to SwingUtilities.invoqueLatter(someRunnable), etc. ad nauseam.... - MVC pattern Most non-trivial swing components rely heavily on the model-view-controller design pattern (often with view and controller coerced into a single class). This way, I can imagine George having a bad time maintaining his table data in a DefaultTableModel while manipulating the table appearance and behaviour in a JTable. BTW, DefaultTableModel is a pretty lame implementation which you should subclass to get some useful functionality. MVC has many advantages but being easy to grasp is not one of them. :-( Conclusion: All in all, doing GUI's "by hand" does not pay off. It's easy to build some trivial useless GUI but anything else is just wasted time. There are very good graphic tools around to do this stuff. These will give you much better code anyway. Even a simple example as Kermit's contains several problems (most of which I simply glossed over). Here is a more correct version (mind you I cannot even be sure it's totally correct!): import javax.swing. class guisample public implements ActionListener properties inheritable static frame = JFrame textfield = JTextField method main(sa=String[]) static -- build a gui and die.. guisample() method guisample -- GUI objects must be instantiated from EDT so -- tell it to do so SwingUtilities.InvokeLater(this.guiBuilder()) method actionPerformed(e=ActionEvent) -- safe here as event handling code is called from EDT say textfield.getText frame.dispose frame=null class guisample.guiBuilder dependent implements Runnable -- SwingUtilities.InvokeLater requires a Runnable so we need -- a separate class :-( method run parent.frame=JFrame("Sample GUI window") parent.frame.setSize(400,100) panel=JPanel() parent.frame.add(panel) parent.textfield=JTextField("Some default text here") panel.add(parent.textfield) button=JButton("OK") button.addActionListener(parent) panel.add(button) parent.frame.setVisible(1) --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by George Hovey-2
On Tue, Oct 5, 2010 at 11:30 AM, George Hovey <[hidden email]> wrote:
> Fascinating, but all news to me. I was in love with Watcom VX-Rexx! CA-Realizer was fascinating like VX-Rexx, but also included something VX-Rexx (to my knowledge) didn´t have... the ability to display and interact with a Spreadsheet and Charting components. Basically you could load and save an array to and from an Excel file! And the spreadsheet component functioned inside your app just a regular spreadsheet. So you could have a spreadsheet on the screen with data, and formulas, surrounded by your own custom GUI buttons, that did operations on the data. And GUI design was all point and click. http://en.wikipedia.org/wiki/CA-Realizer Only an incompetent firm like CA´s management would let it die. Just imagine if it had been open sourced instead of quietly killed.... I still dream of someone coming up with something like CA-Realizer, that generates cross-platform GUI Java Apps... What´s sad is that the components are out there (ie Java spreadsheet components, Excel read-write, Opendocument export-import), but nobody seems to have the vision to integrate all into something like what CA-Realizer was. Language wars are stupid. Everyone thinks they know better and want to "re-invent the wheel" (I´m thinking Python, Scala, Ruby ) when in fact they should stick to the KISS principle (Keep it simple, stupid). Basic and Classic Rexx / Netrexx are the way to go. Java bytecode and the VM environment are the solution to today´s multiple-OSs environments. What´s needed is something that glues the two (easy to understand language, and GUI point and click development, a la CA-Realizer) H*ck, "to do things right, one has to do them by himself", just like MFC must have thought one day . ;-) I wish I had the steady income that would provide me with the time to do this kind of thing (ie build a CA-Realizer like environment on top of Netrexx). FC > On Tue, Oct 5, 2010 at 7:37 AM, Fernando Cassia <[hidden email]> wrote: >> >> On Mon, Oct 4, 2010 at 9:22 PM, George Hovey <[hidden email]> wrote: >> > GUIs certainly are a tough case. But if memory serves, that is exactly >> > the >> > application that brought OO out of the lab and into everyday use in the >> > '90s. I've never heard anyone say that GUI programming can reasonably >> > be >> > carried out with procedural languages >> >> Oh yes it was possible... CA-Realizer, Computer Associates´ Visual Basic >> killer. >> >> I used it under IBM´s OS/2. It was like having today´s Netbeans and >> GUI builder with the ability to write procedural code. >> >> I loved it. Sadly after the win95 epidemic, they dropped their os/2 >> port -CA Realizer 3.0 was in beta and os/2 beta testers were already >> being requested- (i assume some money from Microsoft was involved as >> around the same time frame, CA signed some estrategic agreement with >> MS to integrate CA´s system management with Windows NT....). >> >> Then there was IBM VisualAge for Basic. It was like CA-Realizer but >> using 4x the memory and with apps running several orders of magnitude >> slower. I remember being told that all of VisualAge products used some >> smalltalk runtime, and that the death of all IBM VisualAge products >> was due to this fact. (Another incredible management decision by IBM). >> >> Then for years I´ve chased windmills trying to find: >> >> 1. Anyone who worked at CA-Realizer >> 2. Anyone who worked at IBM VA Basic >> 3. Trying to convince Sybase (which opensourced the Watcom C++ >> compiler as OpenWatcom) to open source Watcom VX-Rexx >> >> Needless to say, I failed miserably at all of them. >> >> So these days basically I throw random rocks in Sun´s general >> direction trying to get the attention of anybody who would listen, >> saying that resurrecting Sun´s Project Semplice would be a good idea. >> >> Prject Semplice was one Sun development, presented at JavaOne2006 (and >> it was working!), where you basically wrote Basic code in Netbeans, >> and got compiled Java bytecode as a result. >> >> Inexplicably, Sun let one of its main engineers leave the firm in >> 2007, and he went to work in Google´s Davlik. Project Semplice was >> dead. >> >> Now, I´m not a compiler author, but wonder if completing the >> incomplete Project Semplice would be such rocket science. H*ck, Oracle >> even owned a Basic-like development tool at one point: Oracle >> PowerObjects... and OpenOffice contans "StarOffice Basic"... so from >> an intellectual property point I don´t think they´d need to pay MSFT a >> dime. >> >> Thoughts? Comments? Expletives? ;-) >> FC >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > -- "It begins with a blessing And it ends with a curse; Making life easy, By making it worse;" -- Kevin Ayers _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by FreeFall
--- Saludos / Kind regards. David Requena El 05/10/2010 14:23, Connor Birch escribió:
Yes, in a way OO can be seen as structuration-taken-on-step-further :-) Mind you that of course these concepts have some twists in the context of object orientation.
hmm.. that would be one of the cornerstones in OO
Every oo language presents its own vision on oo, some better than others. C++ even supports multiple inheritance, which is a nightmare to handle :-(
Not if you're just interested in just using the java library objects. But it would certainly help.
I think the Java API specification is what you would need. The library is indeed very well documented. Take for example the documentation for the toString() method in date I showed before: toStringpublic String toString()
Return values and arguments are specified differently than in NetRexx but it's an easy conversion to do at a glance. public boolean after(Date when) --> method after(when=Date) public returns boolean In short, is there a NetRexx Cookbook?
Once upon a time Dion Gillard had NetRexx adapted javadocs for the java API at his NetRexx FAC website. That site has been long dead now and its archive at wayback machine is incomplete. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
On Tue, Oct 5, 2010 at 12:20 PM, David Requena <[hidden email]> wrote:
> Once upon a time Dion Gillard had NetRexx adapted javadocs for the java API > at his NetRexx FAC website. That site has been long dead now and its archive > at wayback machine is incomplete. Is there any chance to recover this? FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |