> the actual implementation in the `MethodFinder` class. I don't know enough Smalltalk to decipher it :(

For reference, here is the relevant class: https://github.com/pharo-project/pharo/blob/9ad3324bf8aff11e...

A core snippet is:

   foundPermutationSends := (receiver class
    allSelectorsToTestInMethodFinderWithArity: inputCollection size - 1)
    collect:
     [ :method | MethodFinderSend receiver: receiver deepCopy selector: method withArguments: args deepCopy ].

This means, roughly:

- ask the receiver class (in the example above, the class of 2, which is something like SmallInteger) for "all the selectors (= method names) to test" with the given number of arguments.

- for each of these methods, build a MethodFinderSend object, which is at this point is just a container holding a copy of the receiver object, the method to call on it, and a copy of the arguments to test with

Then, given this collection of MethodFinderSend objects:

    ^ (self possibleSolutionsForInput: inputCollection) select: [ :send | send resultIn: expectedResult ].

This means:

- execute the "resultIn:" method on each of the MethodFinderSend and return a collection of those where this returns true

The implementation of this "resultIn:" method is in https://github.com/pharo-project/pharo/blob/c896913a00fa6e2b...:

    [ [ ^ expectedResult = (receiver perform: selector withArguments: arguments) ]
      onErrorDo: [ :anError | ^ false ] ]
       on: Deprecation
       do: [ :depr | ^ false ]

This is, roughly:

- try to perform the call

- return false if there is an exception

- otherwise, return true or false depending on whether the result equals the expected result

So yes, it's an exhaustive search over the methods that the receiver's class promises are OK to test. If you write a method that tries to format the hard drive, and your class exports this method in its "selectors to test", then searching for a method on this class will attempt to format your hard drive.

Thanks for that explanation! Is there any form of sandboxing in Pharo VMs that would prevent accidental side effects like the hard drive reformatting?

Not as far as I know. In fact, the system prides itself on allowing you to modify everything in it.

One striking demo I saw once a few years ago (so details are a bit hazy) involved the become: message. This is a special operation for swapping references around. "X become: Y" has the effect of everything that previously referred to X to now refer to Y, and everything that previously referred to Y to refer to X.

So the demo was to execute something like:

    White become: Black.

which immediately switched all white pixels to black and vice versa.

I think the person giving the demo even demonstrated

    True become: False.

though that made the VM unusable pretty much immediately IIRC.