RE: What the compiler does, or not?

> From: Douglas Handy
>
> I really don't want to start a war here, but I fail to see your
> reasoning on a couple of major points.

Doug, I'll respond, but this is it.  I just hit my dead horse limit.  Three
comments and out.  I really wish some other people would help me out here,
but what the heck.


> Then why switch to free format at all?  Just keep using fixed
> format and MOVE.

New features.  Things are being added to freeform and not to fixed.  I
cannot stay with fixed.


> First off, %editc() is just a valid in fixed format code as with
> free format,
> and anybody who calls themselves a RPG IV programmer who doesn't
> learn the BIFs
> -- even if not using /free -- does not really know RPG IV.

This isn't about being an RPG programmer, Doug.  According to Hans, it's
about clarity, and especially clarity to non-RPG programmers.  THAT'S WHY
THEY TOOK AWAY THE MOVE.  You cannot have it both ways.


> Do you mean to tell me
> after all these years you still look at a reference manual to see
> what various edit codes mean ???

Absolutely.  I don't have space in my head for trivia, that's why there are
reference manuals.  My guess is very few programmers know all the edit
codes.


> And for the record, yes I  *do* think x = %editc(y:'4') is MORE
> clear than MOVE.

That makes two of you.


> And not because I don't understand MOVE -- I do -- but because
> the expression is
> self-evident without having to know or lookup the attributes of
> variable y.

What is self-evident about it?  Without KNOWING what %editc does, you have
no idea.  And if you do know what %editc does, you have no idea whether the
field is binary, zoned, packed, or what.  No idea on size, no idea on
decimal precision, nothing.  The only thing you know is that it is numeric,
and boy, if you can't figure out whether a variable is numeric in a program,
you have other problems.

Anyway, as I said, this is a dead horse issue.  Been there, beaten that
horse.  I'm done.

Joe