C0361@univscvm.csd.scarolina.edu ( Thomas Jenkins) (12/19/90)
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 ;
USES
CRT ;
TYPE
DumbOBJ = OBJECT
PROCEDURE MethodA ;
PROCEDURE InMethodA ;
END ; { DumbOBJ }
VAR
obj : DumbOBJ ;
PROCEDURE DumbOBJ.MethodA ;
PROCEDURE InMethodA ;
BEGIN { DumbOBJ.InMethodA }
WriteLn ( '...In InMethodA!' ) ;
END ; { DumbOBJ.InMethodA }
BEGIN { DumbOBJ.MethodA }
WriteLn ( 'In MethodA.' ) ;
Write ( 'Calling nested method...' ) ;
InMethodA ;
END ; { DumbOBJ.MethodA }
BEGIN
WriteLn ( 'Testing nested methods.' ) ;
obj.MethodA ;
obj.InMethodA ;
END .
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 )?
tom
THOMAS E. JENKINS, JR. +--------+ FROM SHOE +--------+
|"IS THE COMPUTER STILL GIVING |
PROGRAMMER, | YOU TROUBLE?..." |
UNIVERSITY OF SOUTH CAROLINA |"NO, NOT ANYMORE..." |
C0361 AT UNIVSCVM.BITNET |"WHAT DID YOU DO?..." |
C0361 AT UNIVSCVM.CSD.SCAROLINA.EDU |" I TURNED IT OFF." |
+-------------------------------+dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) (12/19/90)
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. Daniel Lewart d-lewart@uiuc.edu
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (12/19/90)
In article <1990Dec18.200336.13056@ux1.cso.uiuc.edu> dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) writes: >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. No, there is a bug if that program compiles in TP 5.5: The identifier InMethodA is defined to be a DumbObj method, so scoping rules say it can't be redefined as a nested procedure in MethodA. TP 6.0 catches the error. Duncan Murdoch
CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) (12/19/90)
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 | +--------------------------------------------------------------------+
dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) (12/20/90)
dslg0849@uxa.cso.uiuc.edu (Some Idiot) writes: > 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. I'm sorry. What I meant to say was: The program does have an unusual feature; it is not a legal OOP ability; it violates scoping rules; it can be explained as a TP5.5 bug; and it appears to be a bug/undocumented feature. Dan
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (12/20/90)
I was thinking about the example of the nested procedure with the same name
as a method, and came up with the following code to test my understanding
of the situation.
type
myobj = object
constructor init(proc:word); { proc is an arg here }
procedure proc; { and a method here }
end;
constructor myobj.init;
begin { the error is here! }
end;
procedure myobj.proc;
begin
end;
begin
end.
To be consistent with the previous error, this should signal a syntax error:
the argument proc and the method proc are in the same scope. It does signal
the error (in TP 6.0, at least), but not until the begin of the constructor.
Could someone with TP 5.5 try this, and see if it finds an error?
I'm coming to think that the design of objects in TP is wrong: a procedure
and its dummy arguments shouldn't be in the same scope. Can anyone comment
on whether this code will compile in different object Pascals?
Duncan Murdoch