Support for blocks behind Morph >> balloonTextSelector is bad style

[marceltaeumel]

Squeak 6.1alpha supports block closures behind Morph >> balloonTextSelector. See Morph >> balloonText.

Yes, both selectors and blocks respond to the message value. However, they are no interchangeable concepts as is.

Proposal:

• Offer balloonTextSelectorOrBlock
• Offer balloonTextBlock

[squeak-smalltalk-bot]

But now!

…

________________________________ Von: Thiede, Christoph ***@***.***> Gesendet: Freitag, 15. August 2025 00:22 Uhr An: ***@***.*** ***@***.***>; squeak-smalltalk/squeak-object-memory ***@***.***>; squeak-smalltalk/squeak-object-memory ***@***.***>; ***@***.*** ***@***.***> Cc: Subscribed ***@***.***>; Marcel Taeumel ***@***.***> Betreff: AW: [squeak-dev] Re: [squeak-smalltalk/squeak-object-memory] Support for blocks behind Morph >> balloonTextSelector is bad style (Issue #136) Forwarding to involved parties - sorry for the noise. I need to fix this in Squeak Inbox Talk. :-)

________________________________ Von: Thiede, Christoph ***@***.***> Gesendet: Freitag, 15. August 2025 00:18 Uhr An: ***@***.*** ***@***.***> Betreff: [squeak-dev] Re: [squeak-smalltalk/squeak-object-memory] Support for blocks behind Morph >> balloonTextSelector is bad style (Issue #136) Sorry for this hack. Of course we can reiterate. But I think this deserves a more fundamental debate. There are many places in the system, especially when using the ToolBuilder, where I wish I could pass a self-contained evaluable such as a block instead of a selector that requires me to define a separate method anywhere. See sends to #help: in Debugger>>#buildFullWith:label: where I got weak. Yes, selectors have their strengths such as avoiding memory leaks and being a compact literal for notifying observers, but in other situations blocks are just more concise and convenient. I know I'm not the only person who is missing this feature. I think it would be interesting if we could establish a general concise pattern for supporting both selectors and evaluables. I wonder whether we really need two separate states for this, which bloats the pattern and could lead to conflicts (shold we use the symbol or the block if both are set?). Then again, I'm also not a fan of type-directed overloading (e.g., consider many signatures in pandas/Python [1]<https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.loc.html>) -- they are less flexible to adapt by new objects (which now also need to implement a type check such as #respondsTo: or #isBlock), and in the worst case, certain types and roles may conflict (see String>>#format: ***@***.***/thread/RTOSJEC6RZNKZC7PKGU3KWEYNUCEJ2BP/>). Yet, the pattern is very tempting - imagine we could do: ```smalltalk index := 0. builder pluggableListSpec new list: self windows; getIndex: [index]; setIndex: [:val | index := val. self changed: #getIndex]; doubleClick: [:val | self inform: 'You clicked on ' , val]; yourself. ```smalltalk ... or would this just not be ToolBuilder any longer? Note we already use a similar pattern in some places such as MenuMorph>>#add:action:, Model>>#menuPragmasFor:in:, and InspectorField>>#valueGetter:. Best, Christoph [1] https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.loc.html [2] ***@***.***/thread/RTOSJEC6RZNKZC7PKGU3KWEYNUCEJ2BP/

--- Sent from Squeak Inbox Talk<https://github.com/hpi-swa-lab/squeak-inbox-talk>

On 2025-08-13T08:55:04-07:00, ***@***.*** wrote: marceltaeumel created an issue (squeak-smalltalk/squeak-object-memory#136) Squeak 6.1alpha supports block closures behind `Morph >> balloonTextSelector`. See `Morph >> balloonText`. Yes, both *selectors* and *blocks* respond to the message `value`. **However**, they are no interchangeable concepts as is. Proposal: - Offer `balloonTextSelectorOrBlock` - Offer `balloonTextBlock` -- Reply to this email directly or view it on GitHub: #136 You are receiving this because you are subscribed to this thread. Message ID: <squeak-smalltalk/squeak-object-memory/issues/136(a)github.com>