[squeak-dev] MethodFinder.Blocks

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Oct 16 09:55:32 UTC 2019


Hi Marcel,


as I see it, this Blocks check only restricts the possible hits, so removing it should not damage any existing functionality. (I am *not* talking about modifying Dangerous!)

And if you do

MethodFinder methodFor: {{#(1 2). [:x | Smalltalk saveSession. false]}.#()} "pls don't run this!"

you will surely expect the side effects to be executed?


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


MethodFinder methodFor: {{#(1 2). #even}. #(1)}. '(data1 reject: data2) '
MethodFinder methodFor: {{#(1 2). #yourself descending}. #(2 1)}. '(data1 sorted: data2) (data1 sort: data2) '

Hey, maybe we should make a small game of it? :-) GuessTheSelectorGame :D

Christoph


________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 16. Oktober 2019 10:54 Uhr
An: gettimothy via Squeak-dev; squeak-dev at mail.squeak.org
Betreff: Re: [squeak-dev] MethodFinder.Blocks

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 <christoph.thiede at student.hpi.uni-potsdam.de>:

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191016/98dec780/attachment.html>


More information about the Squeak-dev mailing list