Re: Strange behavior w/%editc()

Joe,

If it helps any I'm on your side.

IMHO, what we are talking about is RPG programming, not programming in
general.

RPG, like any other programming or spoken language, has it's strengths
and weaknesses.  To try to make RPG like all other languages would be
like saying that all the spoken languages on earth must be the same or
similar to the most used language which is Mandarin Chinese.  The most
used second language is English and in no way are these two languages
even remotely similar.

Like the Germans would ever buy into the idea that either of the above
are superior! :)

(BTW, I'm German, so no flames please)

But back to the technical merits of the below code.  Personally I would
have to grab a piece of paper or read slowly doing the math to work out
what is actually going on.  Even the MOVE solution would require some
research to determine what is actually going on.  Both solutions fail
when there is an increase in LOTSEQ and no increase in LOTNUMBER.  Both
solutions would result in overlaying data that (I presume) should be
retained.

Therefore, I conclude that a MOVE operation tells me that I am replacing
the low order positions of the result field by the length of factor two
quite clearly (RPG speaking) where the below would require the
activation of more brain cells to conclude that it is doing a MOVE.

To me, this is the difference between being verbose vs being succinct.

Unfortunatly, being succinct requires language skills and RPG language
skills are not "programming correct" enough these days.

Joe Pluta wrote:
>
<<SNIP>>
>
> >       eval %subst( lotnumber :
> >                      ( %len( lotnumber ) - %len( lotseq ) ) + 1 :
> >                      %len( lotseq ) ) =
> >              %editc( lotseq : 'X' )
> >

>
> And this is where I have to see that you and I view the issue from
> completely different viewpoints.  To replace MOVE LOTSEQ LOTNUMBER with the
> code above is so intuitively bad to me that I doubt you and I can rationally
> continue a discussion.  This is a case where PC (Programming Correctness) is
> taken to an absurd conclusion.