[squeak-dev] Context >> #compiledCode?

Marcel Taeumel marcel.taeumel at hpi.de
Wed Jan 12 13:36:33 UTC 2022

Hi Christoph --

Just use #homeMethod and you will always get an instance of CompiledMethod.

I don't think it is necessary to deprecate #method in BlockClosure and FullBlockClosure. ... maybe soft-deprecated it with "self flag: #deprecated" without moving it into a Deprecated package... Hmm...

Yet, I think that having #compiledCode understood by a closure would be nice. No, #code would not be a good name because it would not be clear whether your would get the String/Text or the byte codes. ;-) 

Am 10.01.2022 13:55:17 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi all, hi Eliot!

Since the introduction of the Sista bytecode set, we have this behavior:

[thisContext method] value "([] in UndefinedObject>>#DoIt "a CompiledBlock(1651857)"

There were already some confusions around the fact that #method answers an instance of CompiledBlock, and I would not be surprised if we found further bugs that rely on the - now falsy - assumption that #method would answer a CompiledMethod only.

(I think) Marcel has already proposed this in the past: Should we maybe deprecate Context >> #method and replace it by Context >> #compiledCode or just Context >> #code? I think this could make our vocabulary a bit more consistent and help us to avoid future errors. On the other hand, it would be a non-trivial process to update all senders, and we might break existing code (if it's not already broken because it was not designed with Sista in mind).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220112/e3717b4c/attachment-0001.html>

More information about the Squeak-dev mailing list