Tcl Source Code

View Ticket
Ticket UUID: ad6696285cacae8f785f394af0f637c2806b66ee
Title: TclOO filters called for unknown and destructors
Type: Bug Version: 8.6.1
Submitter: apnadkarni Created on: 2014-07-22 03:25:36
Subsystem: 35. TclOO Package Assigned To: dkf
Priority: 6 Severity: Minor
Status: Closed Last Modified: 2015-05-17 12:57:26
Resolution: Fixed Closed By: dkf
    Closed on: 2015-05-17 12:57:26
I'm not sure whether this is a documentation bug, an implementation one. The documentation states "Filters are not invoked when processing an invocation of the unknown method because of a failure to locate a method implementation, or when invoking either constructors or destructors."

However, the sample below shows filters are called for unknown and for destructors (though apparently not for constructors).

(tcl) 76 % oo::class create C {
method m {} {puts m}
method f {args} {puts f; next {*}$args}
filter f
method unknown {meth args} {puts unknown}
(tcl) 77 % C create o
(tcl) 78 % o m
(tcl) 79 % o n
(tcl) 80 % 
(tcl) 80 % o destroy

By the way, [info object call o n] also reflects this.
User Comments: dkf added on 2015-05-17 12:57:12: (text/html)
Corrected the documentation to say that filters are called for unknown method processing. Simpler than changing the current implementation.

dkf added on 2015-05-17 12:04:39: (text/html)
And now I've looked again, the filter is <i>not</i> being called for the destructor. It's being called for the <tt>destroy</tt> method, which is a conventional method (that happens to kill the current object).

dkf added on 2014-09-14 11:12:40: (text/html)
Filters definitely shouldn't be called in the destructor chain. That would be an outright bug.
If they're called in the unknown chain, I might leave that in and alter the docs.

dkf added on 2014-08-17 16:28:43: (text/html)
Side note: <tt>info object call</tt> uses the identical datastructure to the actual call mechanism; it generates a call chain and introspects it instead of generating it and calling along it. (<tt>self call</tt> looks at the current call chain.) It should be enough to just look at the chain without calling it; it still exercises the same builder code.