Re: Defining a function key...

Hello Scott,

You wrote:
>I can't imagine that you have trouble remembering that *INKC is F3, but
>have no trouble remembering that x'33' is the AID byte for F3.   Or
>that the AID byte can be found in position 369 of the INFDS.

No one needs to remember that.  They simply need to remember to include
the correct copy members and use the proper constants.  A decent template
takes care of that.  One intelligent person sets everything up and the hoi
polloi simply use it as standard practice.

--- code deleted ---

>The *INKC part isn't where he's going to struggle.   He'll understand
>when I tell him that KC = F3.   He'll accept that.   He'll think it's
>pretty simple -- just check *INKC to find out if F3 was pressed.

--- code deleted ---

>He's going to be lost.  What the heck is an INFDS?  Why x'33'?  Why
>position 369?   He'll end up saying "Why is checking F3 so difficult
>in RPG?  It's not that complicated in any other language!"

No he won't be.  The reason is he never sees the INFDS or the hexadecimla
values directly.  What he sees is:

        C               IF      keyPressed = KEY_F3

or similar and that takes no explaining at all to someone who will simply
accept that *INKC == F3 but it is more obvious.  I've taught RPG to
hundreds of programmers over the years and none of them have problems with
either method conceptually but almost all of them find the *INKx method
less obvious once methods have been explained.

>But, somehow, some way, people on this list are saying that "*INKx is
>obscure".   I just can't accept this.  You're telling me that defining an
>INFDS isn't obscure?  Knowing that you have to check position 369 isn't
>obscure?  knowing that x'33' is F3 isn't obscure?

You're arguing speciously again.  The details of the AID byte are
certainly obscure but the resulting code is much more obvious.  Once set
up no-one needs to know how it works, they just use it.  You know exactly
why I (and others) prefer the AID byte (or named indicators) because you
state it here:

>The primary reason that people use the AID byte is because they can
>simply code constants that give more readable meaning to their code.
>This makes for (better) code like this:

--- code deleted ---

>Because of the nice name you gave to the value x'33', it's a lot easier
>to read.   But it's still obscure.  Its still a lot harder to explain to
>a beginner.

The 'nice name' is the whole point and actually it's not harder to
explain.  I've done it countless times.  They all easily grasp that the
resulting code is clearer and therefore worth the extra cost -- especially
when that cost can be paid once and hidden away.  *INKx incurs a
translation cost every time it is used.

>And...  this type of "using meaningful names" doesn't do anything that
>you couldn't also do with the *INKx indicators!

It does actually.  You can't do what you're attempting.

-- code deleted ---

>The code is still shorter.  It's still easier to explain to the
>uninitiated.

It's not shorter when the implementation is encapsulated in copy members.
It's not easier to explain pointers to the unitiated.  That's one of the
areas new or junior programmers have the most trouble with.  The AID byte
method also has the advantage of allowing mouse events to be handled in
the same way as function keys.  Try that with the *INKx method! or named
indicators.

Also, your example code is broken and won't work as written.

>How about documentation?

--- stuff deleted ---

>So, which way was more obscure?

Your entire argument here is based on the predicate that someone using the
AID byte needs to understand HOW it works and needs to know where the
documentation is in order to use it.  That's only true for the person who
works it out and sets it up.  As I recall I didn't find it that hard when
I did it decades ago.  No one who simply uses it needs to understand how
it works.  If they want to understand then it can be explained simply as I
did in the missive that started all this.  All my original explanation
needs is the list of hex codes for the keys and some example code.  Simple
stuff.  I used to explain this technique to all my students.  Most of them
never had any difficulties.  Now I tend to show them the named indicator
method because it is a little easier to grasp -- but I still tell them to
forget *INKx ever existed.  I do have to explain *INKx for the same reason
that I have to explain the cycle -- existing code uses it so they need to
understand it to maintain it but that's no reason to continue using it (he
says to bait the unwary and start yet another flood of defensive notes
from all and sundry).

Anyway, I've said my piece and I'm bored by this.  You can have the last
word.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------