|
Hans you might have a point there about some programming.
"Had" a programmer here who would not take the time to teach himself
Query. Turned out he couldn't write anything more complicated than a
report that could be generated by Query.
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
Hans Boldt <boldt@xxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/24/2003 08:19 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
To
rpg400-l@xxxxxxxxxxxx
cc
Subject
Re: Benefits of Sub-procedures
jt wrote:
> ... Similarly I would
> ask, why would anyone want to code this:
>
> parms.transNo = %editc((%dec(transNo:%size(transNo):0) + 1):'X');
>
> in order to increment a transaction number...??? I ask this seriously:
Why
> do you need "rocket science" to add 1 to an alpha transaction number??
> Iirc, seems like only one person on this list even came up with an
> /alternative/, a simple data structure. I guess because if it ain't
> "modern", it ain't cool...
That's really the wrong question. A more appropriate one is this:
Why would anyone want to implement a transaction /number/ as an
alpha string? Many other languages with strong type checking require
similar machinations. For example, in Python, you might code
something contrived like:
n='%.*d'%(len(n),int(n)+1)
(That is, convert the number string to an int, add one. Then format
it as a numeric padded to the length of the original string.)
If you want looser interpretations of numeric and character types,
you could go to Perl or Rexx, which allow mixed character and
numeric operations. But then you'd still have the issue of keeping
leading zeros.
A more appropriate solution for this problem (in any language) would
involve a procedure (remember procedures?) which returns the next
available transaction number as a string. Then, the users of the
procedure are spared the gory details of the actual implementation.
Likewise, a Python programmer would (or should) never code that
crufty statement above. A more typical coding practice would be to
code a "transaction number" class. Getting a new transaction number
would then just require a statement like "transnum=tn.next()". The
details of how the transaction number are implemented belong in the
class, and not in the calling code.
For example, in Python you might code something like:
class Counter:
def __init__(self, start=0, size=5):
self.count = start
self.size = size
def next(self):
self.count += 1
return '%.*d'%(self.size,self.count)
c = Counter(start=234,size=7)
print c.next()
print c.next()
print c.next()
print c.next()
(Sorry for posting Python code in an RPG list. But it's easier to
whip up a Python example to illustrate my point. Don't sweat the
details - just think of it as "executable pseudo-code".)
>
> Businesses are not primarily about coddling people who care a /whole/
lot
> more about looking cool than they do producing a solution, (one that
works
> like the Energizer Bunny (tm, I sure...;-)), and producing it on a
> reasonable timeline (ie, cost). At least, in my experience.
>
Exactly. And that's why programmers in practically all other
programming languages use procedures extensively.
This gets back to my theory that a large number of programmers
really don't want programming to be easier, and I suspect that's
true especially among RPG programmers. Are more modern (that is,
1970's or later) programming techniques like procedures considered
too "cool", and thus suspect? Is RPG programming supposed to be
hard? Are RPG programmers who make programming look hard considered
more capable than programmers who make it look easy?
Cheers! Hans
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.