From: kaba@nowhere.com   
      
   16.7.2012 16:28, evansl wrote:   
   > On Saturday, July 14, 2012 8:41:22 AM UTC-5, Kaba wrote:   
   > [snip]   
   >> ### Option 5: Locking   
   >>   
   >> In this option B notifies A that it is being referred to. In each   
   >> mutating operation of A, or when destructing A, A checks whether it   
   >> is being referred to. If this is the case, an error is generated at   
   >> run-time.   
   >   
   > This Option 5 sounds a bit like MVC:   
      
   -- 8x --   
      
   > Would that be another way of viewing the problem?   
      
   Rather than the MVC, I would perhaps more specifically subscribe to   
   the observer pattern. A generalization of option 5 is then:   
      
   ### Option 6: Observers   
      
   In this option B registers itself to A as an observer. As A faces   
   changes, it notifies of them to all observers B's. If B gets a   
   notification of its underlying A changing, it will raise a run-time   
   error.   
      
   However, this generality is not needed; any change to A during being   
   referred to by a B should raise an error. Therefore that logic can be   
   placed into A, as in option 5.   
      
   --   
   http://kaba.hilvi.org   
      
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)