On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

Because it is not present in 2.0 but I couldn't find any issue about that.

Because it does not work with the block closure implementation that we have now... The thing is that a block in a method like this: [1+2] is not a literal, but it is instead compiled to bytecode that *creates* a new block at execution time. e.g. test ^[1+3] Test new test == Test new test ==> false. The reason is that blocks are realized like this (to save memory!!, you know, we just have 8GB of it in a shity laptop...): 17 <8F 00 00 04> closureNumCopied: 0 numArgs: 0 bytes 21 to 24 21 <76> pushConstant: 1 22 <20> pushConstant: 3 23 <B0> send: + 24 <7D> blockReturn 25 <7C> returnTop So if you now do a #becomeCached like this: becomeCached self becomeForward: ((CachedBlockClosure new: self size) outerContext: outerContext startpc: startpc numArgs: numArgs cachedValue: self value copiedValues: self) is will have no influence, as the next evaluation of the code containing the block will not see the #becomed block but instead the newly generated one. Damien C. was trying to write documentation and the example he tried to do just did not work (the block was always evaluated). Of course it works if you put the block in an iVar, but that then defeats the whole purpose as the idea of the caching block is to not need an ivar to cache... Again a case where we are shoot in the foot by the horrible architecture of the system. Marcus -- Marcus Denker -- http://marcusdenker.de