<div dir="ltr">Hello! I've been experimenting with some improvements for the messages we use to simulate the method lookup (i.e. Behavior>>#lookupSelector:), motivated by the OOP courses I teach (where I like to show the implementation of the method lookup). I figured the changes might be of interest for integration on the Cuis base image, so I'm sending some proposals! The changes I propose are twofold: 1. Change sets 1-2x are a proposal to have a new #lookupSelector:ifAbsent: message, to be able to specify what to do when the selector is not found (instead of always returning nil). The change set labelled 1 introduces it, and the ones labelled as 2x use it in some of the methods we already have. I tried to name the files as descriptively as possible, to help during review. 2. Change set 3 is a proposal for a new implementation of #lookupSelector:ifAbsent:. The implementation I propose avoids using a while loop, it's a recursive implementation which I find a bit less imperative (and, might I say, "more object-oriented"). Surprisingly, the implementation has also better performance compared with the current one (it runs about 30% faster)¹. To be able to evaluate the second proposal, I attach some useful scripts: * Some benchmarks for the average case and two "worst cases". * A (partial) correctness test, which asserts that the methods found by both implementations are the same (traversing all the methods in the image). * A script to try it out with very deep class hierarchies. These scripts should be evaluated manually in a workspace, while switching between the two implementations. I hope you find these changes, if not useful, at least interesting! Cheers! Facu ______ ¹ Of course, being a recursive implementation, it limits the class hierarchy depth by the stack size. But since the depth of all inheritance hierarchies on the image is less than 20, and having a deep inheritance hierarchy is already a design smell, we might consider taking the design + performance improvement. Also, currently the maximum stack size is limited by RAM (at least by default), so the change works with very large hierarchies too (see the attached <a href="http://very_deep_hierarchy_test.st">very_deep_hierarchy_test.st</a> script).</div>