I posted this because it's a fun paper, and implementing object-systems is a fun project for the millions of newbie Lispers and on-the-fence programming language nerds out there.
The unique feature of this paper is that it uses simulation, as opposed to compilation or interpretation, in order to extend a language. I have been saying this for years, language implementation techniques as presented in undergrad studies are actually HARD; the fun, easy techniques are buried in "research" papers like this one.
Looks like they're using a message-passing dispatcher similar to SICP 2.1.3 [1]; it's only a shame that the article predates the formalization of eval [2], though, which leads to anachronisms such as: "In Scheme, [calculating the method given its selector] is not possible. What is missing is the possibility to evaluate a symbol in the environment of self."
I did something similar to this, though much smaller, a while back, using (parts of) JavaScript as the host "functional" language, just as a thought experiment.
It's interesting how much easier it is to assemble functionality with closures in many cases, when all you want is to initialize ("construct") something that you are going to make one (1) call to, or at least one kind of call, repeatedly. Interesting? Maybe obvious.
For a class with many methods, I think OOP does have value, but one does get tired of it being presented as the One Way.
The unique feature of this paper is that it uses simulation, as opposed to compilation or interpretation, in order to extend a language. I have been saying this for years, language implementation techniques as presented in undergrad studies are actually HARD; the fun, easy techniques are buried in "research" papers like this one.