Inspector / Explorer display (printOn:) closures slightly differently

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Inspector / Explorer display (printOn:) closures slightly differently

Jaromir Matas
Explorer/inspector present closures as

[closure] in Class>>method

or:

[] in Class>>method

depending on whether they are printed from Context or BlockClosure #printOn
- by design or by accident? (or have I missed something?)
<http://forum.world.st/file/t372955/Screenshot_2021-02-19_Closure.png>
Thanks,



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

^[^ Jaromir
Reply | Threaded
Open this post in threaded view
|

Re: Inspector / Explorer display (printOn:) closures slightly differently

Jaromir Matas
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

^[^ Jaromir
Reply | Threaded
Open this post in threaded view
|

Re: Inspector / Explorer display (printOn:) closures slightly differently

marcel.taeumel
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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: Inspector / Explorer display (printOn:) closures slightly differently

Jaromir Matas
Marcel,
thanks, I haven't realized the debugger noise consequence - and I agree.
I'll try your suggestions.

I'm enclosing a comparison of what I'd find more helpful and how the current
explorer presents stuff:

<http://forum.world.st/file/t372955/Screenshot_2021-02-22_104737.png>

Thanks again,






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

^[^ Jaromir