On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck <[email protected]>
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
