nsf

- nsfStack.c / CallStackMethodPath(): Providing a fix for reporting   method paths correctly when dispatching to ensembles from alias   parameters. Prior to that fix, the intermediate (and inactive)   CMETHOD frame wrapping configure() calls caused [current   methodpath]s to report empty string elements. Added some test cases. - nsf.c / ObjectDispatch(), DispatchUnknownMethod(): When testing   objects as alias parameter targets, I found cases when the default   (C-level) unknown handler was invoked upon. The result was an   unknown message which reported the delegator object as "unknown"   method! This was due to injecting the delegator object into the   argument vector at position 0, subsequently used by the C-level   unknown handler. First, I tried to make the C-level unknown handler   aware of the ensemble call context (by funneling through the CSC and   frame flags) but this turned out to be complicated to achieve this   simple task. As an alternative, I suggest the following patch: The   first argument in unknown calls is treated as a list, and   dependening on the call context (ensemble vs. non-ensemble) contains   all the necessary call data. For ensemble methods, it is the   delegator object, the entire method path (as returned by [current   methodpath]), and the actual unknown selector. The default C-level   handler, treating the call info as list, resorts to reporting the   last element of the list which is always the unknown   selector. Custom (ensemble-level, application-level) unknown handler   can wrap and further process the information as necessary. To   demonstrate the usefulness, I rewrote EnsembleObject->unknown()   accordingly. I checked for Tcl_Obj leaks. - Added some tests on objects as targets of alias object parameter. To   be continued.

Show less