Tcl Source Code

View Ticket
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to [email protected]
or submit via the online form by Sep 9.
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:

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:

And now I've looked again, the filter is not being called for the destructor. It's being called for the destroy method, which is a conventional method (that happens to kill the current object).

dkf added on 2014-09-14 11:12:40:

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:

Side note: info object call 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. (self call 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.