Re: Clever UNIX/C Constructs

This debate is still raging?!?

John Hall wrote:
>>Evan Harris wrote:
>> The original thread (which I think I started) was based on the premise
that:
>> EVAL Variable = Variable + 5
>> is, in my opinion at least,
>> much more readable and obvious than
>> variable += 5
>I really don't get that argument ???   I can understand if you prefer
>not to use +=  but to state that the eval statement is "much more
>readable and obvious"  Just isn't so.
>
>I would assume that the reason that += only costs $2 is because it IS
>the same as the ADD op code which already exists.  That's all it is

Actually, the listed price is $10.  But it probably should have been
listed as $2.  I wouldn't say it's a "lunch-time diversion", but it's
not much work at all.  In fact, I have it working already in my own
development library!  The only work remaining is a diagnostic or two,
and testing.  (Oh yeah, also writing up the description of the
function.)

So the question of whether or not this should be implemented is, as
far as I'm concerned, moot.

Also, it's not the same as ADD.  Using +=, you can code stuff like:

       string += ' ' + productCode;
       total += cost + tax;

You can't do that with ADD.


>> So far the major argument for providing this syntax has been to save
>> typing: if there is another argument I'd be more than interested to hear
it
>> as I really cannot see what it adds to any language. As per Richard's
>> comments it seems it arose from a design decision due to limitations of
the
>> past - just as the columnar RPG format was rooted in its origins.
>
>No the major improvement is readability.

And maintainability.  As others have pointed out, if you're
incrementing some complex expression, it's easier to get it right
if you only have to type it once.

Oh yeah, also performance.  Consider the statements:

      Totals(FindItem('xyz')) += incr;
      Totals(FindItem('xyz')) = Totals(FindItem('xyz')) + incr;

One statement calls procedure FindItem once, the other twice.
You just might find some use for this.


>> I agree with your statements regarding RPG syntax not necessarily being
>> obvious to the uninitiated, but it seems to me that += etc is just more
of
>> the same from a different language. To make it clear where I am coming
>> from, would you want indicator logic added to C ? Why add something to
RPG
>> that adds nothing content-wise merely additional form ?

There's nothing wrong with looking to other languages for
inspiration.  If we could only add completely original enhancements,
our proposed enhancement list would be rather small indeed!


> Indicator logic may be a poor example since newer versions of RPG are
>eliminating them.  But I would like to see some of the better features
>of RPG added back into C

I'm curious - could you name some RPG things you'd like to see in C?
(Besides, of course, better string manipulation.)

BTW, we're not eliminating indicators, just making them less
necessary.


>> Excuse my ignorance if I get this wrong (I have no more than a passing
>> acquaintance with C) but in the above example what would be the effect
of:
>>
>> variable =+ 5
>>
>> Would it (as I understand it) assign 5 to the variable rather than
>> incrementing it by 5 ? What are the side-effects (bad choice of words
>> possibly) of other incorrectly typed terse assignments ? And what is the
>> effect on debugging to those that are not proficient with this style of
>> expression ?
>
>Should be an illegal expression.  But even if its not it would be the
>equivalent of using a z-add instead of an add.

Perfectly valid C code.  Assigns +5 to the variable.

(If my memory is correct, I believe =+ was the original increment
assignment operator in C.  But there was an ambiguity in the language,
and so later implementations used += instead to allow the more
reasonable interpretation for "x=+5;".)

Anyways, Evan does have a good point that if you mistype += as =+,
you may get a surprise.


>> These days when I code I like to think that I am coding for "whoever
comes
>> next" and that they will (hopefully) be impressed with how easy it is to
>> maintain or (god forbid) debug - not by having to refer to the manual to
>> understand indicators, cycles, expressions or whatever.
>
>Let's face it the argument is truly about what you are used to seeing.
>If someone can master all of the EXISTING quirks of RPG then one more
>"op code" (+=) won't make any difference one way or another.
>
>It would be nice to have but it won't be the end of the world if they
>don't add it.

Here's another take on this argument.  Much of what we've been doing
to the language in the past few releases has been to relieve the
programmer of having to deal with those existing quirks.  I would
argue that a program written to take advantage of the V5R1 language
would be much more maintainable than more traditional RPG programming
style.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---