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 |