Object-method Reform: - changed interface to object specific commands by requiring an ensemble named "object". The rational behind is essentially to use always the same info command to retrieve object specific methods, no matter whether these are defined on a plain object or an a class object (does not break the "contract" what e.g. "info method" returns). Now we define methods via:
The same change propagated as well to the "info" method. Now we have:
/cls/ info methods ... /cls/ info object methods ... /obj/ info object methods ...
Similar, the object parametererization uses /cls/ create obj -object-mixin M /cls/ create obj -object-filter f /metacls/ create cls -mixin M1 -object-mixin M2 /metacls/ create cls -filter f1 -object-filter f2
- as a consequence, a) "/cls/ class method ...", "/cls/ class alias ...", "/cls/ class forward ...", "/cls/ class filter ...", "/cls/ class mixin ...", "/cls/ class info ..." "/obj/ class method require method ..." "/obj/ class method require public method ..." "/obj/ class method require protected method ..." "/obj/ class method require private method ..." were dropped
- use alias-stubs for aliases pointing to objects. This allows us to distinguish between cases, where an object is dispatchable due to the alias or due to allowmethoddispatch (when the object happens to be a subobject and has therefore its cmd in the same namespace). The semantics are now: - aliases to objects are always dispatchable, no matter, how allowmethoddispatch is set. - direct subobjects of objects are currently on dispatchable when allowmethoddispatch is set.
Loading ...