Platon Technologies
not logged in Login Registration
EnglishSlovak
open source software development celebrating 10 years of open source development! Friday, March 29, 2024

Diff for libco/TODO between version 1.6 and 1.7

version 1.6, 2003/03/14 14:29:09 version 1.7, 2003/03/23 11:02:25
Line 12  These should not need explicit object na
Line 12  These should not need explicit object na
 CO_METH respectively. The CO_METH problem is much harder to solve and also a  CO_METH respectively. The CO_METH problem is much harder to solve and also a
 bit more annoying.  bit more annoying.
   
 REFLEXION [target: 0.2.3, done: 40%]  REFLEXION [target: 0.2.4, done: 40%]
 A method should be available for each object that will provide outside world  A method should be available for each object that will provide outside world
 with informations from method table of object. By means of copp it should be  with informations from method table of object. By means of copp it should be
 incorporated in message table of every prototype object.  incorporated in message table of every prototype object.
   
 AUTOMATIC CONSTRUCTOR [target: 0.2.3, done: 20%]  AUTOMATIC CONSTRUCTOR AND SHALLOW COPY [target: 0.2.3, done: 20%]
 Our copp should generate constructor for each object. The data initialization  #Our copp should generate constructor for each object. The data initialization
 should take place in "bless" method - in a way, that allows to re-send this  #should take place in "bless" method - in a way, that allows to re-send this
 message to object and cause it to reset itself (e.g. after cloning).  #message to object and cause it to reset itself (e.g. after cloning).
   UPDATE: The object should provide it's size and so, for automatic
   single-constructor and single copy-func approach can be used. Might be of use
   when implementing different alloc methods.
   
 CLONE [target: 0.2.4, done: 15%]  SEPARATE MESSAGE EXCEPTION STACK [target: 0.2.3, done: 0%]
   The co_m_v should use separate stack, so cox_push/cox_pop pairs can cross
   message boundaries (eg. message returning unpopped value)...
   
   CLONE [target: 0.2.4, done: 30%]
 This should replace current constructor approach. There will be constructor,  This should replace current constructor approach. There will be constructor,
 but only as a prototype creation mechanizm, and it will be autogenerated by  but only as a prototype creation mechanizm, and it will be autogenerated by
 copp. It will set up message-handler table for the object and so on. But more  copp. It will set up message-handler table for the object and so on. But more

Legend:
Removed from v.1.6  
changed lines
  Added in v.1.7

Platon Group <platon@platon.org> http://platon.org/
Copyright © 2002-2006 Platon Group
Site powered by Metafox CMS
Go to Top