<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Facu,</p>
    <p>Just ntegrated and pushed to GitHub. Thanks!</p>
    <p>Cheers,</p>
    <div class="moz-cite-prefix">On 2026-09-21 2:18 PM, Facundo Javier
      Gelatti via Cuis-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAC1UKnaA-Yv_mO5i47uz0N8-ZgOLD3DBMjS3-mDycv7ADGfRMw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hello!<br>
        <br>
        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!<br>
        <br>
        The changes I propose are twofold:<br>
        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.<br>
        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)¹.<br>
        <br>
        To be able to evaluate the second proposal, I attach some useful
        scripts:<br>
        * Some benchmarks for the average case and two "worst cases".<br>
        * A (partial) correctness test, which asserts that the methods
        found by both implementations are the same (traversing all the
        methods in the image).<br>
        * A script to try it out with very deep class hierarchies.<br>
        These scripts should be evaluated manually in a workspace, while
        switching between the two implementations.<br>
        <br>
        I hope you find these changes, if not useful, at least
        interesting!<br>
        Cheers!<br>
        Facu<br>
        <br>
        ______<br>
        ¹ 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"
          moz-do-not-send="true">very_deep_hierarchy_test.st</a>
        script).</div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis.st">www.cuis.st</a>
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich</pre>
  </body>
</html>