Here is a proto of COCLASSPATH-less, coextend-less OOP.
coinsert and other co's still exist and used.
This sounds like a good idea. I tried removing COCLASSPATH and coextend
from the scripts, replacing with coinsert, and everything works fine.
So, unless we hit some showstoppers, the next beta will have the
simplified code
Oleg's suggestion uses the sentences
create_pshape_ f. 0{::y
codestroy_pshape_ f. ''
which will fail in locked scripts, because "create_pshape_ f." is
no different from "create_pshape_"
The sentence
create_pshape_ f. 0{::y
will do less harm because it will create nouns inside pshape locale,
the worest case is that different instances of pshape share the same
value. But
codestroy_pshape_ f. ''
is detrimental. If any instance calls "destroy", it will erase
locale 'pshape' itself, not the locale of the object. Any further
reference to pshape will cause syntax error because the locale
no longer exists.
Of course, the above errors will not occur if script is not locked.
IMO COCLASSPATH is the correct way to implement class inheritance
because it keeps the static parent-child relationship. coninsert/
copath is a dynamic attribute that is not related to inheritance.
For example, it is possible at any time, add or delete another class in copath,
on the other hand class inheritance is a static relationship. As COCLASSPATH
is already hidden from user, I can not see any material need to decommit it.
BTW I learnt oop from "Object-oriented Software Construction" by Bertrand Meyer.
Although this book is rather old (published in 1988), its explanation is very
clear.
Just my 2 cents.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
