RE: Strange behavior w/%editc()

(sigh) Joe, I don't believe I expressed an opinion, so how can you know it?

<chuckle>When we consider opinions expressed, Joe, you're certainly close to
the top of the list of the scorched-earth society in defending your own; all
the prosecution has to do is look in the archives!</chuckle>.  At risk of
giving you some slight reinforcement, I'll acknowledge nodding my head in
agreement with many of your positions, appreciating your insight into
several issues, and knowing more now than I did before I started reading
your columns (oops, "JT" reference).

I /am/ surprised you didn't chastise Simon for daring to offer a cogent
rebuttal or for resorting to a foreign (not dead, in my book) language.  Are
we killing the messenger?

In regard to your example, you score an excellent point (more slight
reinforcement).  From a coding standpoint, a straight MOVE is convenient and
not error-prone...at least not until the size of one of the variables
changes, and that could cause a problem.  IMHO (happy now?), the EVAL/SUBST
combination offers some explanation of the intent of the code for
(programmer + 1).  Personally, I'm trying to avoid this specific situation
and use a DS to provide clarity.

While it's nice to "tell" the language labs what to do, they have their own
not-necessarily-bad agenda; I think they get softened up just fine by the
body blows from this NG.  RPG developers are the users (and customers) of
the RPG compiler, and while programmer "convenience" needs to be high on
their list of priorities, it can't be their only priority: there are
practical considerations in every "application", whether it's a compiler,
customer inquiry program, or PCS400.  Those priorities include backward
compatibility and future development.  Without having any secret insight. I
suspect the path of RPG compiler development is not as wide as one would
think.

Unfortunately, the problem we face is our own: MOVE is sloppy/flexible/magic
(take your pick) and we used it like Enron used stockholders and employees,
even when we had data structures to clarify the intent of the
implementation.  We got through indicators (we did, didn't we????) and we'll
get through this.

I'll let the rest of you sort it out; free-form RPG is not in the future of
my package for a few years (unless IBM PTF's it back to older versions).

With best regards,
Reeve

-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
Behalf Of Joe Pluta
Sent: Thursday, February 28, 2002 9:01 AM
To: rpg400-l@midrange.com
Subject: RE: Strange behavior w/%editc()

>> From: Simon Coulter
>>
>> The complementary operations
>> can be handled in a similar manner but I leave that as an exercise for
>> the reader.
>>
>> So, exactly what business need cannot be serviced by the above
>> replacements?  Exactly how are the MOVE variants clearer or easier to
>> code than the EVAL replacements?
>>
>> Quod erat demonstrandum!

> From: Reeve Fritchman
>
> Simon, thanks for a fine summary.  But what makes you think logic will
> overcome opinion?

I love it when you take a backhanded whack at anybody who disagrees with
you, Reeve.  It's so endearing.

In any event, if, in your mind

    eval %subst(lotnumber : 3 : 8) = %editc(Lotseq : 'X')

is a logical replacement for

    MOVE LOTSEQ LOTNUMBER

then fine.  I disagree.  I think the extra coding is unnecessary.  Not only
that, but to keep the exact equivalence (that is, the code will still put
the lot sequence in the last six positions of the lot number, regardless of
the size of my lotnumber field), I have to do this:

    eval %subst(lotnumber : (%len(lotnumber) - %len(lotseq)) + 1 :
%len(lotseq)) =
         %editc(lotseq : 'X')

As always, the devil is in the details.  It's the part that's left to the
student that's the hardest.

Joe

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