Smalltalk - Re: MethodFinder.Blocks

Smalltalk › Squeak › Squeak - Dev

Re: MethodFinder.Blocks

Posted by marcel.taeumel on Oct 16, 2019; 8:54am
URL: https://forum.world.st/MethodFinder-Blocks-tp5105421p5105545.html

Hi, Christoph.

The method finder (or selector browser) has a hard-coded list of possible results (or messages) to not trigger dangerous side effects. Any new feature, such as that "quasi higher-order-message" symbol , would have to be added. Sure. But keep compatiblility with block arguments. :-)

Just curious: what would be the block example for these examples?

MethodFinder methodFor: {{#(1 2). #even}. #(1)}

MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}.

Especially the latter seems kind of cryptic to me.

Best,

Marcel

Am 14.10.2019 01:27:12 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

I just got irritated as I evaluated

MethodFinder methodFor: {{#(1 2). #even}. #(1)}

and got no hit.

This is because the MethodFinder stores an extra list of selector parameters that are assumed to require a block argument (Blocks) -- but nowadays this requirement is not given, as you can pass a Symbol, MessageSend, SortFunction or whatsoever, thanks to polymorphy. So (how) is this block check still relevant? If I remove it, I get the right hit and can do thinks like

MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}.

Also, #ifError: will prevent any error thrown if the block does not match the selector.

Looking forward to your answers :)

Christoph