Ticket UUID: | b9e1a3032eb1fb7811996bcbdddbeaa8004c589a | |||
Title: | TclOO method lookup chooses object method over class mixin method | |||
Type: | Bug | Version: | 8.6.0 | |
Submitter: | apnadkarni | Created on: | 2014-07-22 03:39:29 | |
Subsystem: | 35. TclOO Package | Assigned To: | dkf | |
Priority: | 8 | Severity: | Minor | |
Status: | Closed | Last Modified: | 2014-08-28 07:58:17 | |
Resolution: | Fixed | Closed By: | dkf | |
Closed on: | 2014-08-28 07:58:17 | |||
Description: |
The manpage for [next] states in the Method Search Order section that methods defined in classes mixed into classes of an object are searched before methods defined for the object. The following sample seems to show otherwise. oo::class create ClassMixin { method m {} {puts ClassMixin; next} } oo::class create ObjMixin { method m {} {puts ObjMixin; next} } oo::class create C { mixin ClassMixin method m {} {puts C} } (tcl) 82 % C create o ::o (tcl) 83 % oo::objdefine o {mixin ObjMixin} (tcl) 84 % info object call o m {method m ::ObjMixin method} {method m ::ClassMixin method} {method m ::C method} (tcl) 85 % oo::objdefine o {method m {} {puts object; next}} (tcl) 86 % o m ObjMixin object ClassMixin C (tcl) 87 % info object call o m {method m ::ObjMixin method} {method m object method} {method m ::ClassMixin method} {method m ::C method} Again, not sure if the bug is in the docs or the implementation | |||
User Comments: |
dkf added on 2014-08-28 07:58:17:
This should now be fixed. (The code to fix it is actually a fairly simple double traversal with flags tracking what we've seen, except for the case where we're dealing with filters in mixins, which is a bit brain-boggling.) Aggressive user testing encouraged. dkf added on 2014-08-19 07:31:17: And looking at the code, I can remember why I didn't get this right. Figuring out what should happen when you've got a class mixed into a class that is inherited by a class mixed into a class that we've instantiated (eek!) makes my head hurt. dkf added on 2014-08-19 07:19:54: Oh, I remember this! Implementation bug (in the call chain builder) indeed. I can tell it has to be that way round, because otherwise there's no meaningful difference between class mixins and normal inheritance. |