Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!NORUNIX.BITNET!knut-skog%rglab.uit.uninett From: knut-skog%rglab.uit.uninett@NORUNIX.BITNET (Knut Skog) Newsgroups: comp.windows.news Subject: Class vars or Instance vars, conclusion Message-ID: <102*knut-skog@rglab.uit.uninett> Date: 14 Mar 89 08:06:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 My comments on this issue may have propagated some of my own confution. My current understanding is that the values of composite instance variables are shared dispite being an "instance". This is demonstrated by the following example; % The test should be executed incrementaly in three steps as indicated. % Step1: Make your own subclass /MyClass DefaultWindow dictbegin /InstComposite (Instance string) def dictend classbegin /ClassComposite (Class string) def /PaintClient { /Helvetica-Bold findfont 18 scalefont setfont 100 100 moveto InstComposite show 100 50 moveto ClassComposite show } def classend def /MyCInst1 framebuffer /new MyClass send def { /FrameLabel (Inst 1) def } MyCInst1 send /reshapefromuser MyCInst1 send /map MyCInst1 send % end Step1 % Step2: Change Instance value. { /InstComposite ClassComposite def % Some dict or an array assignment is % more likely in real } MyCInst1 send % end Step 2. % Resize window to see the to strings being equal. % Now we believe that our instance , its values inclusive, % is non shared (traditional interpretation). % We modify the composite value of our class object: % Step3: { ClassComposite 0 188 put } MyClass send % end Step3. % We have not done anything explicitly to MyCInst. However, % having instructed a change in our class definition, when it % is repainted, we see that the instance variable (InstComposite) % of our first instance has been changed indirectly! % Hence composite values of instance vars are shared because composite % def-ing in PostScript is by reference (not by value). Knut