Hello.
I was hunting down a problem of our custom views not being GCed.
They were held by KeyboardProcessor>>keyboardConsumers. I browsed
KB to find the correct way to remove them and I found the following
oddities:
KB>>addKeyboardReceiver: aController
keyboardConsumers add: aController.
aController controller keyboardProcessor: self.
Argument clearly says it is CONTROLLER but all invokers pass VIEW
and even the method itself expects aView because no Controller
understands a message #controller.
KB>>removeKeyboardReceiver: aController
| indx |
indx := self keyboardConsumerIndexFor: aController.
indx > 0 ifTrue: [keyboardConsumers removeAtIndex: indx].
currentConsumer == aController ifTrue: [self setCurrentConsumer: 0].
Argument says it is a Controller and all invokers pass CONTROLLER
(what a relief ;-) ).
KB>>keyboardConsumers is a collection of VIEWS but ALL KB methods
ask for (and work with) their CONTROLLERS.
Finally, KB>>currentConsumer is one of 0, nil or a CONTROLLER. Why?!
I would like to know if this mess is intensional and I missed its
cleverness or if it is a suspect for refactoring in which case I
would propose two solutions:
1) Add Controller>>controller to return itself and pass whatever
you like. But this is really a hack.
2) Refactor KB to work only with Controllers, because Controllers
have the back link anyway. This is a clean solution but backward
compatibility might be a problem.
Just my 2 cents,
Ladislav Lenart
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
