Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!adm!news
From: CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel)
Newsgroups: comp.lang.pascal
Subject: Re: Why does this work in TP ?
Message-ID: <25305@adm.brl.mil>
Date: 19 Dec 90 15:29:29 GMT
Sender: news@adm.brl.mil
Lines: 65

In article 1990Dec18.200336.13056@ux1.cso.uiuc.edu,
  dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) wrote:

>C0361@univscvm.csd.scarolina.edu (Thomas Jenkins) writes:
>
>> The program below has an unusual feature.  Is this considered a
>> legal OOP ability?  See the question below after looking at the
>> code.
>>
>>  [Program ObjectTest]
>>
>>  If you compile the above code, the output looks like:
>>
>> Testing nested methods.
>> Inside MethodA.
>> Calling nested method......In InMethodA!
>> ...In InMethodA!
>>
>> Isn't this a violation of scopeing rules?  I notice this behavior
>> in a large object system and boiled it down to this.  Anyone up to
>> explaining this behavior?  Is this legal or a
>> bug/feature/undocumented feature ( <-this last one because I can't
>> remember reading this as legal )?
>
>The second line of output is actually 'In MethodA'.  Chapter 5 of
>the TP 5.5 OOP Guide, section 'Method calling conventions', states
>the following:
>
> Methods always use the FAR CALL model, regardless of the
> setting of the $F compiler directive.  [Capitalization is Borland's]
>
>Thus there is no unusual feature in the program; it is a legal OOP
>ability; it is not a violation of scoping rules; it can be
>explained; and it is a legal documented feature.

Not to pick nits, but I don't see that the use of NEAR or FAR CALL
has anything to do with scoping, which is a feature of the language
rather than the machine architecture. I also don't see that
documenting methods' use of FAR CALL means that this behavior has
been documented.

As Thomas Jenkins discovered and Tony Papadimitriou
(<37KGLLQ@CMUVM.BITNET>, in an article dated Tue, 18 Dec 90 19:56:41
EST on the PASCAL-L list) verified, although TPas 5.5 accepts,
compiles and executes this code, TPas 6.0 rejects it at compile
time:

Turbo Pascal  Version 6.0  Copyright (c) 1983,90 Borland International
SAMPLE.PAS(27): Error 4: Duplicate identifier.
  PROCEDURE   InMethodA;
              ^
I'm not convinced that "duplicate identifier" is the appropriate
message here, or that a compile time error should occur. However, as
Thomas Jenkins wrote his code, I _am_ persuaded that InMethodA
should not be visible outside the scope of DumbOBJ.MethodA.

Ah, well, disagreements make elections and horse races--and
compilers, it appears. <grin>

+--------------------------------------------------------------------+
| Karl Brendel                           Centers for Disease Control |
| Internet: CDCKAB@EMUVM1.BITNET         Epidemiology Program Office |
| Bitnet: CDCKAB@EMUVM1                  Atlanta, GA, USA            |
|                        Home of Epi Info 5.0                        |
+--------------------------------------------------------------------+