RE: IBM's RPG Strategy (was: Long Procedure Names) -- RPG400-L

I knew I should have gone back to that session on Tuesday--but I'm sort of
glad I didn't I may have been too frustrated.
Scott got it right and is more politically correct than I am when he said in
response to the proposed EVAL-CORR opcode... "I definitely prefer to avoid
having a punctuation symbol in an opcode name!"
Dashes in opcodes, such as in On-ERROR, is an exception and should not now
nor ever be considered strategic direction for RPG. Any opcode with dash in
it (except for the old Z-ADD/Z-SUB which are deprecated) should NEVER be
introduced in the release version of the compiler. 
Eval-Corr  myDS = yourDS
Is that EVAL minus CORR? Huh?
I'd rather use the COBOL MOVE CORRESPONDING, at least that means something
to me. 
How about Eval(C) instead?
I'd even settle for an ambiguous MCORR (move corresponding) opcode over
EVAL-CORR.  

On the EVAL(O) opcode (Hey why don't they call it Eval-Overlay? <vbg>) I
think this is just proof that the %SUBST() built-in function name is too
damn long and should have been %SST from the start. They're willing to add
EVAL(O) but not just supplement the built-ins with %SST? How does EVAL(O)
help with the right-side of the equals sign? It doesn't

On PROCEDURE OVERLOADING, I have to say this is important to RPGIV, but not
unless and until they first solve problems with parameter types. I'm
referring to relaxing the ridged design of RPGIV-written subprocedure
parameter data types and lengths. 

On the EXJSP opcode--I think JSPs are important to a lot of people using
RPGIV but there are two things wrong with this opcode. (1) Its name is
horrible. Execute is not contemporary to IBM and RPG IV, and JSP should not
be in the name. Perhaps SNDRCV would be better. And (2) As I just implied,
it should not be limited to JSPs. Architecting in a technology de jour is
contrary to what the developers have been saying. While I believe CGI-calls
should be part of RPGIV none of those calls are specify to CGI, but rather
to communicating with a web browse. I mean %getenv() %stdout, etc. Where are
the things we needed yesterday, today and tomorrow. 

Oh well... CGILIB and CALLP are my toolset and seemingly will continue to be
for a long, long time.

-Bob Cozzi
www.RPGxTools.com
If everything is under control, you are going too slow.
- Mario Andretti


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Steve Richter
Sent: Wednesday, March 23, 2005 4:38 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: IBM's RPG Strategy (was: Long Procedure Names)

On Wed, 23 Mar 2005 15:04:27 -0700, John Taylor
<lists@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Paul,
> 
> Please don't bring up "Object Rpg", or I'll then have to wade through a
> dozen "don't try to make RPG like Java" posts. :)
> 
> However, it doesn't look like there's any chance of such a thing happening
> to RPG anytime soon. Scott Klement has an article on IBM's RPG strategy
> here:
> 
> http://makeashorterlink.com/?S48D13CBA

I just read the list of what is being considered and I am
underwhelmed. Respectfully, I think George Farr and all the other IBM
language decision makers should replaced.  IBM needs to think bigger
than this.  Instead of adding some more %bifs, open up the compiler
with exit points so a programmer can write their own built in
functions.   Follow the lead of Microsoft and develop a CLI
specification that enables modules written in C++, RPG and Java to be
used interchangeably.  Modular, reusable and portable code is the
objective.  Give us a language that supports constructors and
destructors and we can write our own XML parser.

-Steve
-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.