From: Alan
_1_ I for one very much LIKE knowing how the compiler internals work,
especially in the case of this definition. Especially since we will be
dealing with cross-language issues.
Remember, I'm not saying you can't use VARYING(2) and VARYING(4) if you want
to. I'm saying that programmers who don't care about the length if the
prefix (that's any programmer who never takes the %addr of a VARYING field)
shouldn't have to care.
_2_Allowing an implicit higher maximum length for VARYING would break
some existing code! At least theoretically.
Like where ___%addr( VaryingField ) + 2___, for example, is used in
reference to a received parameter in a called subprocedure in an
"obscure" service program. It's something that sophisticated programming
shops would have to check for if they ratchet up their max to 100,000
for a VaryingField.
This is going to happen whether you code VARYING(4) or VARYING on the
D-spec. The idea of letting VARYING default to VARYING(4) doesn't affect a
single program, called or calling. All it does is make it so that
programmers can use VARYING fields without ever having to know anything
about the internals.
My sole point is that programmers ought to be able to use VARYING fields
without knowing their internals, just as they can today.
That's the way I might even pass the thing to a second subprocedure to a
C-type variable that does something, like use a C-function. And I'd
rather have a syntax issue raised by the compiler than the one suggested
by Joe. IMO.
Again, I think you misunderstand the simplicity of what I'm asking. I'm not
asking for any additional changes to how the language works. A field
defined with VARYING(4) would act the same way no matter what. I'm just
saying that a programmer wouldn't be force to type those characters; the
compiler would figure it out based on the length of the field.
If you prototype a call with a smaller field and pass a larger field, you'll
get an error either way. If you instead pass the address of the field as a
pointer, the compiler has no idea what you're passing, and you won't get an
error either way.
The only thing that my suggestion changes is whether or not you need to type
"(4)" after VARYING on a field >65535 bytes long. No syntax checking
changes, no internal programming changes, nothing. It just means that
people can use large VARYING fields without having to remember to type in
the "(4)" when a field passes a magic length.
But really, at the end of the day, it's a pretty simple issue. The argument
is really almost insignificant: either force programmers to type "(4)" or
don't. At the end of the day, it's more of a philosophical issue: is the
programmer supposed to understand all of the internals of a language before
they use it, or should they only have to learn them when they need them?
Joe
midrange.com
