[GNU-COBOL] Re: Global files issues moot

["Mark E. Adelsberger" <mea@umr.edu>]

Chad (slaught@umr.edu) wrote:

> The issues of global constants is moot.
> 
> I told you to add an assert to you code.. this was WRONG!
> 
> What you need to do is just change teh interface of the function
> to accept an unsigned int as the length...then forget about
> the assert all to gether... If an error gets thru to your code...
> its probably not an error...the unsigned will give me what I want...
> the simplest thng possible(right laura)
> 
> Since no constraint is need, no problems.

Two comments:

First, the error will have to be checked somewhere, and I see no reason
why the runtime's debug mode shouldn't test for it.  Nonetheless, I'll
write it whichever way I'm told to write it; there may be issues I don't
follow here.  But, I will say that if this is, as it appears to me, just
a way to bury our heads in the sand and ignore the issue we were
discussing, then it is a bad idea.

Second, regardless of whether this is the correct behavior, it doesn't
make the issue moot; it just puts more time between now and when the
issue has to be resolved, and that's a poor excuse to stop discussing
it.


The issue, for those who weren't involved, was this:  It was suggested
that the IO runtime should use assertions to ensure that the length
that CobolIO__accept_string() is given is in the range (0, max] where
max is the maximum length of a string in COBOL.  So, should such a
constant be defined within the IO runtime (and then separately in any
other lib that needs it), or should a global constant file be kept that
holds it?

My position is that, since it is a value that is true of the language as
a whole, it should be globally defined.  Otherwise, if it ever changes,
all instances must be tracked down and changed.  And, there's the chance
for inconsistancy among the values.

(I'd include the rebuttal to this position, but I haven't heard one.  All
I've heard is the opposing point of view, which I address now.)

The opposing view, as I understand it, is that such a file would create
a global dependency, which should be avoided.

While I understand that it's generally bad to have global dependencies,
that's not the only force at work.  To think that there's a simple set
of rules on which basis every decision can be made is a dangerous
mistake.

My point is this:  there either are or are not constants that are globally
true about COBOL and on which multiple modules depend.  Our design and
implementation decisions will not affect that truth; they exist or they
do not.  If they don't exist, then the issue would never come up; there
would be no constant that more than one module would wish to use, so
clearly nothing would go in a constant file other than in each module.

But if they do exist, then so does a dependency of those modules on that
constant.  We can pretend that dependency doesn't exist, in which case
when the constant changes we'll have to manually resolve the dependency
whose existance we've been denying.  Or, we can acknowledge the dependency
and let make take care of it for us.

Note that, as long as none of the constants change, this won't actually
cause make to do any additional work anyway.


And that is my 37 cents on the issue...

-- 
Larkinson's Law:  All laws are basically false.

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to gnu-cobol@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.