Re: Code problems with Perform Thru Exit causes fall through
- From: Richard <riplin@xxxxxxxxxxxx>
- Date: Sun, 29 Jul 2007 14:54:38 -0700
On Jul 30, 2:25 am, "Rick Smith" <ricksm...@xxxxxxx> wrote:
"Richard" <rip...@xxxxxxxxxxxx> wrote in message
So you do agree that they are equivalent and it is just a choice ?
That is the SECTION does not add anything that, for example, would
make the compiler do better checking.
No! In particular, paragraph-names need only be unique
within a section.
I will grant you that paragraph names only need be unique within a
section and that it is not necessary to qualify the name. However,
this need not be a 'good thing', the compiler may not warn about
'missing' or misspelled labels. For example if two sections were
supposed to have the same paragraph name but one became corrupted or
was misspelled then the code would silently use the wrong one. There
is no actual 'encapsulation'.
I would also say that this was a really useful feature in the 60s when
huge monolithic programs had to be built by several programmers
because CALL was not available (it was added to ANS'74). Now there are
actual mechanisms that do real encapsulation.
Others may use paragraph-names that
are unique within the program (for example, a prefix on
every procedure-name) and thus obtain some degreee
of equivalence. Since I am not concerned, generally, with
paragraph-names outside the section, any attempt to
modify "my" programs to remove the section keyword
could result in paragraph-name conflicts.
At least the compiler would tell you where those were.
I don't know that sections "would make the compiler do
better checking"; but I believe it helps me to do better
writing.
Yes, encapsulated code and defined interfaces is better writing.
Grouping related code is better writing. But you are not using any
compiler features to enforce this as would happen with sub-programs or
classes, it is better writing by manually imposed discipline.
Except that the compiler will resolve conflicting
paragraph-names to the same section containing the
GO TO statement.
Some years ago I had sent a proposal to J4 that suggested the addition
of label qualifiers. For example adding a LOCAL qualifier to a
paragraph label would ensure that it could only ever be referenced
from within the enclosing section *. While, as you say, the compiler
will resolve first of all to the same section, if by error or
misspelling it does not exist, the compiler will then resolve to
wherever it can can find the name and this may not cause an warning or
error.
In any case I no longer regard 'GO TO' as better programming, not
since ANS'85.
Perhaps there is some confusion concening EXIT SECTION
versus EXIT PARAGRAPH. As it applies to COBOL 2002,
EXIT SECTION may occur anywhere within the section to
the same effect. It is moving EXIT PARAGRAPH that may
create some problems; but EXIT PARAGRAPH is unrelated
to the use of sections.
You are probably correct. I decided years ago that these were
unnecessary in the style of coding that I use and were merely another
way of doing a GOTO while pretending not to. In any case it is
unlikely that I will ever use a 2002 compiler.
But is only a manually imposed so-called 'mini-program'. There is
nothing in the language that assists them. as for example is done with
sub-programs. They are not actually isolated, especially not the data
they use.
Paragraph-names are isolated. Isolation of local or
private data requires a naming convention.
No. Paragraph names are _not_ actually isolated. There is nothing
preventing code in one section to perform a paragraph in another. It
may be that the compiler will attempt to resolve to a local name
first.
Sticking the word SECTION on it makes zero difference, it is only your
self-imposed discipline that creates this alleged 'isolation' and lack
of 'ad hoc coupling'. There is no actual 'interface' in any real way,
merely the way you order the code.
Well, there is a difference in regard to paragraph-names.
And, ...
move data to section-interface-input
perform section-name
move section-interface-output to data
is as real an interface as the equivalent call to a separate
program.
No more so than PERFORM paragraph-name where that was the same first
paragraph to a related group of paragraphs. But then you wouldn't be
able to GOTO xx-exit or exit section, which is the difference that I
said in the first place.
It is in the defining of the interface as actual
data description entries that makes the interface real
Exactly, it has nothing to do with the use of the SECTION word.
and, while I suppose some discipline may be required to
prevent ad hoc coupling, I see it as less of an imposition
when using sections. I think this is because procedural
programming is about procedures and using sections as
major procedures implemented by paragraphs as minor
procedures stands out better than paragraph groups.
I think that mixing performs of sections with perform of paragraphs is
poor programming and I have no problem grouping paragraphs together
into related groups without using the SECTION word.
I can think of many features that would assist in ensuring this but
the word SECTION does none of them.
* The qualifiers that I proposed (that I can recall) were FROM,
PERFORMED, ABOVE, LOCAL.
LOCAL meant only accessible from within the section. FROM meant it
could be subject of a GO TO. ABOVE meant it could be dropped into from
the previous paragraph. PERFORMED meant it could be performed. If any
qualifier(s) were used it restricted the program to those specified.
Example:
ABC SECTION PERFORMED.
ABC-1 ABOVE LOCAL.
...
GO TO ABC-Exit.
ABC-2 PERFORMED LOCAL.
...
ABC-Exit FROM LOCAL.
EXIT.
ABC could only be performed. Drop thru into it would cause run time
error.
Drop thru into ABC-2 or ABC-exit also run time error.
GO TO ABC-exit from anywhere outside the section is compiler error.
ABC-1 can only be dropped into (from the perform of ABC).
However, J4 quite rightly rejected this as there were better ways of
encapsulating.
.
- References:
- Code problems with Perform Thru Exit causes fall through
- From: Lizette Koehler
- Re: Code problems with Perform Thru Exit causes fall through
- From: Richard
- Re: Code problems with Perform Thru Exit causes fall through
- From: Doug Miller
- Re: Code problems with Perform Thru Exit causes fall through
- From: tlmfru
- Re: Code problems with Perform Thru Exit causes fall through
- From: Richard
- Re: Code problems with Perform Thru Exit causes fall through
- From: Rick Smith
- Re: Code problems with Perform Thru Exit causes fall through
- From: Richard
- Re: Code problems with Perform Thru Exit causes fall through
- From: Rick Smith
- Re: Code problems with Perform Thru Exit causes fall through
- From: Richard
- Re: Code problems with Perform Thru Exit causes fall through
- From: Rick Smith
- Code problems with Perform Thru Exit causes fall through
- Prev by Date: Re: Question regarding uniqueness
- Next by Date: Re: Mainframe developer Required Immediately - Permanent position - Dublin Ireland
- Previous by thread: Re: Code problems with Perform Thru Exit causes fall through
- Next by thread: Re: Code problems with Perform Thru Exit causes fall through
- Index(es):
Relevant Pages
|
|