Re: RpgMap: a versatile key/value store for ile rpg

Yet, even for those who know RPG, SLL is mostly meaningless, the RPG keyword is SETLL. Similarly RDN is equally meaningless as READ or READE is the RPG equivalent. I should be able to at least read the abbreviations and get them correct. The other issue I have with this library is that even though the concepts of lists and trees are well established the vocabulary in this library is brand new, and this could put off guys with a different background. What would be wrong with rm_insert(), rm_get() and rm_remove()? The functions names are readable, and they make sense to a large number of folks. You could even add rm_push() and rm_pop() to give it a stack feel, or rm_queue(), rm_dequeue() to give it a queue feel. These function names are exceedingly cryptic.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----John Yeung <gallium.arsenide@xxxxxxxxx> wrote: -----
To: "RPG programming on the IBM i (AS/400 and iSeries)" <rpg400-l@xxxxxxxxxxxx>
From: John Yeung <gallium.arsenide@xxxxxxxxx>
Date: 07/22/2017 05:47PM
Subject: Re: RpgMap: a versatile key/value store for ile rpg


Mihael also preferred longer and more descriptive names. I am less
opposed to the shorter names. I don't think I would have chosen
*these* names, but I probably would have chosen shorter than what you
and Mihael seem to prefer, and I don't have a particularly strong
negative reaction to these names.

There is a school of thought that goes: You have to learn keywords
anyway. They have special meaning in the language, just like you would
learn mathematical symbols. If there aren't too many of them to learn,
and they will be showing up all over the place, it is nice to have
them short. Variables and functions you write yourself can have names
as descriptive (and as verbose) as you want.

But by no means are you alone. Agreeing with Mihael already puts you
in good stead. I think there are lots of programmers and language
designers on both (or all?) sides of the issue of how to choose
keywords.

John Y.