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
- Replaced errorneous check using the object-specific rather than the class-specific options in the query mode of ::nsf::relation with class-filter. This prevented [::nsf::relation /cls/ class-filter] from returning any filter info. As a consequence, the incremental interface of the filter slot failed (e.g., [/cls/ filter add aFilterProc] effectively reset the class-filter cmd list instead of adding to it). Thx are due to Markus Moldaschl for reporting the issue. - Aligning class-filter and object-filter behaviour on errors during filter additions to the state-preserving behaviour of object-mixin and class-mixin. - Adding basic tests on object-filter/class-filter (::nsf::relation, filter slot interface) and specific ones to cover the above issues.