Opensource.Platon.SK CVS: libco/TODO - diff

   Up to  [Platon] / libco
Diff for libco/TODO between version 1.7 and 1.8


version 1.7, 2003/03/23 11:02:25
version 1.8, 2003/03/30 10:26:43



Line 1 




Line 1 




 MESSAGE TABLE CREATION [target: 0.2.1, done: 100%]
 


 
 


 TABLE-DRIVEN DEFAULT MSG HANDLER [target: 0.2.2, done: 100%]
 ::: NEAR FUTURE :::


 At least for now it should use simple cycle comparing received message id with
 


 method table items one by one. When found, method shalt be executed, if not,
 CLONE [target: 0.2.3, done: 40%]


 default action taken (i.e. "default" method invoked, which then could take
 This should replace current constructor approach. There will be constructor,


 care of implicit delegation et cetera).
 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.


 
 More types of cloning should be available: shallow copy, deep copy,


 
 stand-alone, etc. This will then affect way objects are coupled - as with


 
 default, method tables are shared - and thus adding (or removing) method at


 
 runtime will affect all such objects. Stand-alone cloning will create new


 
 method table and thus new object group.


 
 


 
 NEW OBJECT STORAGE [target: 0.2.3, done: 80%]


 
 Object is stored as type + message pointer + data pointer + extensions.


 
 Message pointer is called directly (no destroy handling or alike). Data


 
 pointer is self-explantory. The extensions are provided for things like events


 
 or method tables. You can stuff as much things as you like there, but this is


 
 static -- you must know size when object is constructed and it can't be


 
 changed. You might use this for data if you like, but you will have to write


 
 your own constructor for this object (and maybe make other precautions --


 
 which means this is nothing but hassle).


 
 


 
 NEW MESSAGE SENDING APPARATUS [target: 0.2.3, done: 70%]


 
 No care is taken from the message sending function (co_m, co_m_v), it only


 
 passes the arguments to message handler. This message handler should come from


 
 an extension, which uses the extension area of object to store its


 
 administration (method table or deferred universal message handler).


 
 


 
 NEW OBJECT DELETION METHOD [target: 0.2.3, done: 40%]


 
 Objects will be deleted by simply sending "delete" message with no parameters.


 
 Delete method of an object shalt send "destroy" to itself or defer this action


 
 until object is unused. May take other precautions. Shalt be safe to send from


 
 anywhere (asynchronous thread or method of same object). Destroy retains it


 
 previous meaning - do not call! Also, destroy should now call appropriate


 
 extenstion cleanup function (like co_ev_destroy).


 
 


 
 NEW BLESSING SCHEME [target: 0.2.3, done: 40%]


 
 Each object type has these crucial components: flavour (with it's creation


 
 function) and bless (initialising flavour-specific data and object's data


 
 pointer). The flavour initialisation is provided by it's implementation.


 
 


 
 COPP REWRITE [target: 0.2.3, done: 0%]


 
 The copp preprocessor shalt be rewritten, using sensible framework (like


 
 iotta ;]). Also, it should separate different parts into different modules,


 
 allow selecting features for each run (like python-wrappers-only or


 
 object-support only), support object flavours et cetera.


 
 


 
 ::: DISTANT FUTURE :::


 
 


 MORE INTELLIGENT CO_ATTR [target: 0.2.2, done: 100%]
 


 MORE INTELLIGENT CO_METH_INI [target: 0.2.x, done: 0%]
 MORE INTELLIGENT CO_METH_INI [target: 0.2.x, done: 0%]


 These should not need explicit object name, just get it from last CO_OBJECT or
 These should not need explicit object name, just get it from last CO_OBJECT or


 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




Line 17  A method should be available for each ob




Line 58  A method should be available for each ob




 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 AND SHALLOW COPY [target: 0.2.3, done: 20%]
 


 #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
 


 #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.
 


 
 


 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,
 


 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
 


 types of cloning should be available: shallow copy, deep copy, stand-alone,
 


 etc. This will then affect way objects are coupled - as with default, method
 


 tables are shared - and thus adding (or removing) method at runtime will
 


 affect all such objects. Stand-alone cloning will create new method table and
 


 thus new object group.
 


 
 


 PLUGIN ARCHITECTURE [target: 0.2.5, done: 50%]
 PLUGIN ARCHITECTURE [target: 0.2.5, done: 50%]


 Create consistent framework built on libltdl for loading modules. Each module
 Create consistent framework built on libltdl for loading modules. Each module


 shalt become object in loading process and export its interface this way.
 shalt become object in loading process and export its interface this way.




Line 46  shalt become object in loading process a




Line 65  shalt become object in loading process a




 AUTOMATIC PYTHON BINDINGS [target: 0.2.6, done: 30%]
 AUTOMATIC PYTHON BINDINGS [target: 0.2.6, done: 30%]


 All co objects should be import'able and instantiable from python. Also, their
 All co objects should be import'able and instantiable from python. Also, their


 methods should be accessible through default pythonish interface (eg a.test
 methods should be accessible through default pythonish interface (eg a.test


 ("blee") should send message "test" to object "a" with string argument "blee").
 ("blee") should send message "test" to object "a" with string argument


 
 "blee"). And they should be buildable separately from rest of library, so they


 
 don't drag python dependency into all libco-using projects. Like


 
 libco-python.so.


 
 


 SECURITY [target: 0.3.1, done: 0%]
 SECURITY [target: 0.3.1, done: 0%]


 Fix buffer overflows and alike.
 Fix buffer overflows and alike.


 
 


 
 INTO - INTERFACE OBJECT PROTOCOL [target: 0.3.x, done: 0%]


 
 Protocol and support infrastructure for program visualisation independent of


 
 interface. Should use IGLUE modules - interface glue - for each interface


 
 type. Program written with INTO support should support all interfaces for


 
 which IGLUE modules are available.


 
 


 
 DATABASE SUPPORT MODULE [target: 0.3.x, done: 0%]


 
 Database independent inetrface with postgresql as reference platform.


 
 


 CO_MAP ASSOCIATIVE ARRAY [target 0.3.2, done: 0%]
 CO_MAP ASSOCIATIVE ARRAY [target 0.3.2, done: 0%]


 CO_BTREE BINARY TREE IMPL [target: 0.3.5, done: 0%]
 CO_BTREE BINARY TREE IMPL [target: 0.3.5, done: 0%]


 THREAD SUPPORT [target: 0.4.x, done: 0%]
 THREAD SUPPORT [target: 0.4.x, done: 0%]


 
 


 
 ::: DONE :::


 
 


 
 MESSAGE TABLE CREATION [target: 0.2.1, done: 100%]


 
 TABLE-DRIVEN DEFAULT MSG HANDLER [target: 0.2.2, done: 100%]


 
 At least for now it should use simple cycle comparing received message id with


 
 method table items one by one. When found, method shalt be executed, if not,


 
 default action taken (i.e. "default" method invoked, which then could take


 
 care of implicit delegation et cetera).


 
 


 
 MORE INTELLIGENT CO_ATTR [target: 0.2.2, done: 100%]


 
 


 
 SEPARATE MESSAGE EXCEPTION STACK [target: 0.2.3, done: 100%]


 
 The co_m_v should use separate stack, so cox_push/cox_pop pairs can cross


 
 message boundaries (eg. message returning unpopped value)...









Legend:


Removed from v.1.7
 


changed lines


 
Added in v.1.8



















Platon Group <platon@platon.org> http://platon.org/
  Up to  [Platon] / libco
-version 1.7, 2003/03/23 11:02:25
+version 1.8, 2003/03/30 10:26:43
 Line 1
 Line 1
 Line 1
- MESSAGE TABLE CREATION [target: 0.2.1, done: 100%]
- TABLE-DRIVEN DEFAULT MSG HANDLER [target: 0.2.2, done: 100%]
+ ::: NEAR FUTURE :::
- At least for now it should use simple cycle comparing received message id with
- method table items one by one. When found, method shalt be executed, if not,
+ CLONE [target: 0.2.3, done: 40%]
- default action taken (i.e. "default" method invoked, which then could take
+ This should replace current constructor approach. There will be constructor,
- care of implicit delegation et cetera).
+ 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.
+ More types of cloning should be available: shallow copy, deep copy,
+ stand-alone, etc. This will then affect way objects are coupled - as with
+ default, method tables are shared - and thus adding (or removing) method at
+ runtime will affect all such objects. Stand-alone cloning will create new
+ method table and thus new object group.
+ NEW OBJECT STORAGE [target: 0.2.3, done: 80%]
+ Object is stored as type + message pointer + data pointer + extensions.
+ Message pointer is called directly (no destroy handling or alike). Data
+ pointer is self-explantory. The extensions are provided for things like events
+ or method tables. You can stuff as much things as you like there, but this is
+ static -- you must know size when object is constructed and it can't be
+ changed. You might use this for data if you like, but you will have to write
+ your own constructor for this object (and maybe make other precautions --
+ which means this is nothing but hassle).
+ NEW MESSAGE SENDING APPARATUS [target: 0.2.3, done: 70%]
+ No care is taken from the message sending function (co_m, co_m_v), it only
+ passes the arguments to message handler. This message handler should come from
+ an extension, which uses the extension area of object to store its
+ administration (method table or deferred universal message handler).
+ NEW OBJECT DELETION METHOD [target: 0.2.3, done: 40%]
+ Objects will be deleted by simply sending "delete" message with no parameters.
+ Delete method of an object shalt send "destroy" to itself or defer this action
+ until object is unused. May take other precautions. Shalt be safe to send from
+ anywhere (asynchronous thread or method of same object). Destroy retains it
+ previous meaning - do not call! Also, destroy should now call appropriate
+ extenstion cleanup function (like co_ev_destroy).
+ NEW BLESSING SCHEME [target: 0.2.3, done: 40%]
+ Each object type has these crucial components: flavour (with it's creation
+ function) and bless (initialising flavour-specific data and object's data
+ pointer). The flavour initialisation is provided by it's implementation.
+ COPP REWRITE [target: 0.2.3, done: 0%]
+ The copp preprocessor shalt be rewritten, using sensible framework (like
+ iotta ;]). Also, it should separate different parts into different modules,
+ allow selecting features for each run (like python-wrappers-only or
+ object-support only), support object flavours et cetera.
+ ::: DISTANT FUTURE :::
- MORE INTELLIGENT CO_ATTR [target: 0.2.2, done: 100%]
  MORE INTELLIGENT CO_METH_INI [target: 0.2.x, done: 0%]
  These should not need explicit object name, just get it from last CO_OBJECT or
  CO_METH respectively. The CO_METH problem is much harder to solve and also a
-Line 17  A method should be available for each ob
+Line 58  A method should be available for each ob
 Line 17  A method should be available for each ob
 Line 58  A method should be available for each ob
  with informations from method table of object. By means of copp it should be
  incorporated in message table of every prototype object.
- AUTOMATIC CONSTRUCTOR AND SHALLOW COPY [target: 0.2.3, done: 20%]
- #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
- #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.
- 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,
- 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
- types of cloning should be available: shallow copy, deep copy, stand-alone,
- etc. This will then affect way objects are coupled - as with default, method
- tables are shared - and thus adding (or removing) method at runtime will
- affect all such objects. Stand-alone cloning will create new method table and
- thus new object group.
  PLUGIN ARCHITECTURE [target: 0.2.5, done: 50%]
  Create consistent framework built on libltdl for loading modules. Each module
  shalt become object in loading process and export its interface this way.
-Line 46  shalt become object in loading process a
+Line 65  shalt become object in loading process a
 Line 46  shalt become object in loading process a
 Line 65  shalt become object in loading process a
  AUTOMATIC PYTHON BINDINGS [target: 0.2.6, done: 30%]
  All co objects should be import'able and instantiable from python. Also, their
  methods should be accessible through default pythonish interface (eg a.test
- ("blee") should send message "test" to object "a" with string argument "blee").
+ ("blee") should send message "test" to object "a" with string argument
+ "blee"). And they should be buildable separately from rest of library, so they
+ don't drag python dependency into all libco-using projects. Like
+ libco-python.so.
  SECURITY [target: 0.3.1, done: 0%]
  Fix buffer overflows and alike.
+ INTO - INTERFACE OBJECT PROTOCOL [target: 0.3.x, done: 0%]
+ Protocol and support infrastructure for program visualisation independent of
+ interface. Should use IGLUE modules - interface glue - for each interface
+ type. Program written with INTO support should support all interfaces for
+ which IGLUE modules are available.
+ DATABASE SUPPORT MODULE [target: 0.3.x, done: 0%]
+ Database independent inetrface with postgresql as reference platform.
  CO_MAP ASSOCIATIVE ARRAY [target 0.3.2, done: 0%]
  CO_BTREE BINARY TREE IMPL [target: 0.3.5, done: 0%]
  THREAD SUPPORT [target: 0.4.x, done: 0%]
+ ::: DONE :::
+ MESSAGE TABLE CREATION [target: 0.2.1, done: 100%]
+ TABLE-DRIVEN DEFAULT MSG HANDLER [target: 0.2.2, done: 100%]
+ At least for now it should use simple cycle comparing received message id with
+ method table items one by one. When found, method shalt be executed, if not,
+ default action taken (i.e. "default" method invoked, which then could take
+ care of implicit delegation et cetera).
+ MORE INTELLIGENT CO_ATTR [target: 0.2.2, done: 100%]
+ SEPARATE MESSAGE EXCEPTION STACK [target: 0.2.3, done: 100%]
+ The co_m_v should use separate stack, so cox_push/cox_pop pairs can cross
+ message boundaries (eg. message returning unpopped value)...
 Legend:


Removed from v.1.7
 


changed lines


 
Added in v.1.8
 Legend:


Removed from v.1.7
 


changed lines


 
Added in v.1.8
-Removed from v.1.7
+Added in v.1.8


Copyright © 2002-2006 Platon Group Site powered by Metafox CMS	Go to Top