I've just been working the whole day on the OPAL decompiler, getting it
almost to run (already works for various methods). Now ...
could someone please explain to me why the current implementation of
closures isn't a terribly bad idea?
I can see why it would pay off for Lisp programmers to have closures
that run like the Pharo closures, since it has O(1) access performance.
However, this performance boost only starts paying off once you have at
least more than 4 levels of nested closures, something which, unlike in
LISP, almost never happens in Pharo. Or at least shouldn't happen (if it
does, it's probably ok to punish the people by giving them slower
performance).
This implementation is pretty hard to understand, and it makes
decompilation semi-impossible unless you make very strong assumptions
about how the bytecodes are used. This then again reduces the
reusability of the new bytecodes and probably of the decompiler once
people start actually using the pushNewArray: bytecodes.
You might save a teeny tiny bit of memory by having stuff garbage
collected when it's not needed anymore ... but I doubt that the whole
design is based on that? Especially since it just penalizes the
performance in almost all possible ways for standard methods. And it
even wastes memory in general cases. I don't get it.
But probably I'm missing something?
cheers,
Toon
