From: Barbara Morris
Okay, at the risk of being a little pedantic, I will address your points one
more time. Because we're veering into the land of opinion, this is where it
can really drag out, so I'll try to be very concise, and I think if you're
still adamant about your position, I'll just have to accept your position
and move on. As I've said before, your opinion (particularly the language
designer opinion) is the one that matters.
I still stand by the answer I gave to Buck
http://archive.midrange.com/rpg400-l/200705/msg00587.html, which is that
RPG is a compiled and strongly-typed language, and RPG programmers have
to be specific about the types.
Okay, I absolutely agree with this. A programmer must be clear about
specifying type and length of field. That's a given. However, they
shouldn't have to specify (except implicitly) the amount of storage or the
internal format of the field.
If I specify 10U0 or 10I0, I get basically the same internal storage layout.
If I specify 10U0 and 5U0 I get the same type of internal layout, but
different lengths. If I specify 5U0 and 5S0, I get completely different
internal layout and size.
I don't think that having VARYING with no parameter mean something
different depending on the length would make things easier for the new
programmer in the long run.
This is where I disagree; we do that all the time. 10U0 means something
different than 5U0, and only because of the declared length of the field.
RPG has allowed this kind of
flexibility/simplicity in the past, and it has caused grief for even
expert programmers, often with parameter passing, and occasionally with
subfield definition. For example, you can define a numeric variable
with just the length and decimals; depending on where you code it, it
means "P" or "S". Another example is date and time definitions;
depending on what is in the H spec, the DATFMT has a different default.
These examples are a little different. I'm not talking about the default
value being different in two different programs. The default will always be
the same: two byte prefix for anything up to 65536, four byte for everything
larger (until we get to 4GB fields).
D myBigVar s 100000A VARYING
This will always mean the same thing: a 100,000 byte field with a four-byte
prefix.
One might argue that we shouldn't force all RPG programmers to enter P
or S for numerics and we shouldn't force all RPG programmers to enter
DATFMT for all their date fields just because some RPG programmers can't
be bothered to learn how RPG works. I would argue that if RPG
programmers always had to be specific about their data types, there
would be far fewer questions about why PGM1 can't successfully call PGM2
when they both explicitly defined their variable as 5 with 2 decimals.
Okay, this is the part where the discussion starts to get subjective. The
line about "some RPG programmers can't be bothered to learn how RPG works"
is a little harsh, in my opinion. I know LOTS of RPG programmers who are
very, very smart individuals and who use RPG to solve business solutions.
They might even use VARYING, but really don't care how the language does it.
They're thankful that it does, but they pretty much consider that the
language's job, not theirs. They want to use the language to solve business
problems. And in my mind, the goal of a language, especially of a business
language, is to make the programmer's job as easy as possible.
I submit that this list is probably a cross-section of some of the better,
brighter minds in the RPG community. Even so, how many people here use
%addr(VARYING)+2? What percentage of people on this list actually care
about the internals of the VARYING field? My guess is that the number is
less than 10%. Requiring an explicit prefix length means the other 90% now
need to understand how the compiler internals work.
By requiring RPG programmers to be specific about the size of the
varying prefix, we can forestall future problems with parameter passing
and subfield definitions.
The argument about using a VARYING field in a data structure is an
interesting one. For a few cases it might save some work; there are
certainly instances where the length of a variable field is specified in a
separate binary length field. But I submit that's got nothing to do with
the default. If you're counting on the internals of a VARYING field inside
of an API data structure, I agree that you ought to specify the prefix
length.
Not requiring them to be specific about the
prefix size actually forces them to know more about the details of the
data type; they have to know that 65536 is the magic switchover point
(not to mention 4294967296 at some possible far future time that would
trigger an 8-byte prefix).
I don't agree. For the business-oriented programmer who simply wants the
language to keep track of the lengths of his character data (like a Java
StringBuffer), then he never needs to know about the switchover point. RPG
will always hide that complexity from him.
It's requiring the length that forces programmers to learn the cutoff point:
that whenever they specify a field with more than 64K bytes, they have to
put "(4)" on the end of VARYING. Sure, they'll remember it eventually, but
it's unnecessary.
The most likely problem to occur from this is when a programmer tries to get
the length of a long field and stuff it into a numeric value that's too
small, because they're used to using 5S0 or 5U0 fields. Of course, the
compiler could check for this and issue a warning.
The parameter-passing problems are eased to some extent by prototyped
parameters, but it is sometimes very confusing for programmers to
understand what the compiler is complaining about.
See, that's the thing. The problem is completely removed by prototypes for
people that don't mess with the prefix lengths. Because prototypes check
for field length, if the field lengths don't match, the prototype would fail
anyway. And since two fields with the same length always default to
pointers with the same length, the point is moot.
In fact, the only person who could screw up the game is someone who decides
to take a 128 byte field and force it to use a 4-byte prefix. And that
person, I submit, should be smart enough to figure out why the compiler is
complaining. Of course, the compiler COULD give a slightly different error
message ("Incompatible VARYING field prefixes").
Anyway, enough on this. It's really a very subtle distinction and it only
matters for those people who need huge VARYING fields. The requirement to
make someone type three essentially redundant characters is not earth
shattering; I just want to make sure that the language is not being tailored
for a tiny minority at the expense of the ease of use of the overwhelming
majority. If, in your mind, you think programmers' lives will be better by
making them enter the length on the VARYING, then you are the designer and
it's of course your decision.
I just wanted to plead my case.
Joe
midrange.com
