Hi Jaromir, hi all.

Hmmm.... I think the way context's are printed is fine. Their primary use is the debugger stack. Adding the prefix "context" would be too noisy:



Yet, I suggest that we somehow improve the representation of BlockClosure in the Inspector and ObjectExplorer. Note that there is no need to change #printOn:. In a custom ClosureInspector, a custom "source code" field could be added, similar to CompiledCodeInspector. Maybe also list all the closured bindings, similar to ContextInspector. To improve Object Explorer, there could be a new entry to show the source code as well via a custom #explorerContents.

(Which reminds me that we should really improve the composability of inspectors, which is currently not possible due to the way how "self" is provided to inspector fields. I tried that once in MorphInspector to use DictionaryInspector for the custom properties in MorphExtension ... but failed to do so, looking at #streamPropertiesOn:)

I do tend to mix up Closure and Context from time to time, given that their printOn: is very similar. :-D Changing the printOn: from "[closure] in ..." to "closure [] in ..." wouldn't help me.

Best,
Marcel
 
Am 21.02.2021 14:20:22 schrieb Jaromir Matas <m at jaromir.net>:
I suspect "[closure] in Class>>method" really means:

closure: [] in Class>>method

while "[] in Class>>method" actually points to a context:

context: [] in Class>>method

I understand a "closure" is, in fact, a block in a context. For a beginner
"[closure]" is really cryptic and confusing...

In addition, seeing "sender =
FullBlockClosure(BlockClosure)>>valueWithExit:" really twisted my brain :)
The sender is, indeed, a context.


May I suggest something more consistent to provide a clear clue e.g.:

sender... context [] in Class>>method

receiver... closure [] in Class>>method

analogous, though redundant:
outerContext... context [] in Class>>method
closureOrNil ... closure [] in Class>>method

Thanks a lot. Regards,



-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210222/8954c0c4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 102876 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210222/8954c0c4/attachment-0001.png>