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 | |||
Description: |
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} } ::C (tcl) 77 % C create o ::o (tcl) 78 % o m f m (tcl) 79 % o n f unknown (tcl) 80 % (tcl) 80 % o destroy f 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. <p> 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. |
