[Oberon] I have been defeated.

[Andreas Pirklbauer]

I must add that the last comment below doesn't really apply to Original Oberon in fact (as MenuViewer.Restore will of course set the "right" X, Y, W, Z in the copy) - I forgot that I've made and I'm making a series of changes in Experimental Oberon to support arbitrary composite viewers.. 
      From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
 To: Douglas G. Danforth <danforth at greenwoodfarm.com>; Oberon List <oberon at lists.inf.ethz.ch> 
Cc: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
 Sent: Sunday, June 26, 2016 9:05 AM
 Subject: Re: [Oberon] I have been defeated.
   
I just used MenuViewers.Copy (unchanged) from Original Oberon:
  PROCEDURE Copy (V: Viewer; VAR V1: Viewer);    VAR Menu, Main: Viewers.Viewer; M: Viewers.CopyMsg;  BEGIN Menu := V.dsc; Main := V.dsc.next;    NEW(V1); V1^ := V^; V1.state := 0;    M.V := NIL; Menu.handle(Menu, M); V1.dsc := M.V;    M.V := NIL; Main.handle(Main, M); V1.dsc.next := M.V;    V1.dsc.next.next := NIL; V1.dsc.parent := V1; V1.dsc.next.parent := V1; V1.parent := NIL  END Copy;
The two sub frames V1.dsc and V1.dsc.next are copied as well , which is what Original Oberon calls a deep copy. But in the case of TextFrames the respective texts F.text point to the same text as the sub frames of the original viewer (see TextFrames.Copy for the details).
If one attached the *original* descendants to the copy of the composite object, then how could their X, Y, W, W be different? Wouldn't that require a change in the frame's definition (making X, Y, W, Y part of an extended object or something)? I didn't want to go that far. But happy to consider if I see how it's done elsewhere and what the benefits are.


      From: Douglas G. Danforth <danforth at greenwoodfarm.com>
 To: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> 
 Sent: Sunday, June 26, 2016 1:47 AM
 Subject: Re: [Oberon] I have been defeated.
  
 "If a shallow copy would be desired, the descendants would not have to be copied, and the original descendants instead of their copies would be attached to the copy of the composite object."
 
 That is the behavior you want.  An editor (writer) that changes the state of an object must operate on only one object.  The viewers (readers) of the object see the same state change.
 
 If you did a deep copy then there would be two objects.  An edit of object 1 would not be seen by a viewer of object 2.
 -Doug Danforth
 
 On 6/25/2016 3:23 PM, Andreas Pirklbauer wrote:
  
 Douglas, 
  In Experimental Oberon, the changes to the original are *also* seen in a clone created by System.Clone. In fact, its copy behaviour is exactly the same as System.Copy, except that the copy is created in a separate virtual logical display area. I'm not so familiar with Blackbox, but I used the term "deep" as it it used in the Project Oberon book section 4.4.2 (referring to the way descendants of a composite object are copied): 
  "As a fine point we clarify that the above algorithm is designed to create a deep copy of a composite object (a menu viewer in our case). If a shallow copy would be desired, the descendants would not have to be copied, and the original descendants instead of their copies would be attached to the copy of the composite object." 
  It's just semantics.. Andreas 
  
 
 

   

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160626/c660fd8d/attachment.html>