× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hear, hear, Tom!

Steve Richter wrote:
7. Re: will v6r1 RPG support main procedure recursion? (Steve
Richter)

a GC makes the coding and usage of a procedure library much easier.
people post often that they use Java methods from RPG to do things
like create PDF documents or read from spreadsheet
files. RPG procedures and service programs are good. but
arguably not good enough because we have to use a GC language to get
the rich functionality we need.

Hmmm... "we [ have ] to use a GC language to get the rich functionality
we need"...

I disagree. I believe it should be worded "we [ choose ] to use a GC
language to get the rich functionality we
need". And I believe that the reasons for making that choice are based
in the same kinds of things that
eventually allowed microcomputers to beat out mainframes in the
Computer Chess Championships.

I agree with you Tom. I have not read all contributions to this thread,
however almost every mail I /did/ open had some assumption built in that
because of GC (affectionally called GC language) a myriad of nice
functions would become available. Now somebody might have already said
this, but GC (at least in Java) is not mandatory. Yes, the Virtual
Machine needs to implement the interface (that is, a call to the GC
methods must be allowed) but noone has specified that the VM needs to
/do/ anything. Better still, it is explicitly mentioned in every Java
book I've read that you need to assume that /nothing/ will happen when
you call such a method. So effectively GC adds nothing at all to the
programming environment, only a promise that may never be kept and can
most certainly not be relied upon (there is rooms for puns about
politicians and diplomats here: <
).

What languages as Java contribute is the promise that programs which
have been coded once can be run on many platforms. And because of the VM
regulations (many interfaces and their behaviour laid down in "laws",
and a plethora of specifications documented) a developer on platform A
can safely assume that the program will behave in a similar fashion on
any other platform assuming that the same VM regulations have been met
(along with a list of requirements about the running environment like
availability of JDBC etc.).

Now to state that you can only get to the rich functionality you need
through the use of a GC language can be very true for the situation at
hand, but it is not thanks to GC, the GC happens to be present in the
language your department/company chose. I totally agree with others who
have said that similar functionality is present on the iSeries (if not
through RPG, then through some API) and perhaps not readily available,
but the pieces are there to be assembled into another nice API. It might
be more work (no, it is more work) however the flexibility offered is
priceless.

So, avoid any misunderstandings, I suggest that the focus should be
placed upon accessability of functions and system resources and not on
GC.


<snip>

In short, we don't "have" to. It just tends to make sense to "choose"
to. We're not dumb. Common sense can sway >decisions.

And this about sums up what I have tried to say.


Cor


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.