Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: new() type checking in Object languages
Message-ID: <4013@internal.Apple.COM>
Date: 1 Sep 89 18:09:39 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 39
References:<4590@portia.Stanford.EDU> <11615@polya.Stanford.EDU>

In article <11615@polya.Stanford.EDU> johnmark@Neon.Stanford.EDU (John M. 
Agosta) writes:
> duggie@Jessica.stanford.edu (Doug Felt) writes:
> 
> 
> > I believe Object Pascal restricts assignments in one direction but not
> > the other.  I am not sure but I think the assignment is a runtime
> > restriction, in that code is generated to check the class of the
> 
> Yes, in MacApp beta9 the assignment coercion is checked by code at
> runtime. This appears to be different than previous versions, 
> coercions that I ported over to beta9 now break into the debugger

Object Pascal has always signalled a compile-time error if you try to 
assign a variable of one class to a variable of a subclass.  Such an 
assignment might not be valid because the object being assigned might not 
be compatible with the target type.

The way to avoid the error is to coerce the object to the target type (or 
a subclass of the target type).  In Object Pascal, the coercion has always 
generated a run-time check to ensure that it was valid.  (This code is 
generated only when range-checking is enabled in the compiler, so extra 
code isn't present in final versions of a program.)

What I believe has changed in the latest version of MacApp, is that it 
does more checking to ensure that the objects you are dealing with are 
valid objects and not uninitialized variables, freed objects, etc.  (This 
is the "object discipline" feature.)  

What could be happening is that you are trying to coerce a NIL (or freed) 
object and MacApp is complaining, where it didn't before.  I would be 
interested in finding out what the exact circumstances were.


Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1