Julian Rohrhuber

I'd propose to make a check if: 1. there are three argNames, exactly 2. the third argName is `keywordArgumentPairs`, exactly Then the probability of trouble is acceptably low, and mainenance...

A search in github is interesting: https://github.com/search?q=%22super.doesNotUnderstand%22&type=code Almost a half of the code calls `super.doesNotUnderstand(selector, args)` the other half `super.doesNotUnderstand(selector, *args)`. So there seems to be confusion about this topic...

There are problems if: - a subclass implements doesNotUnderstand with 3 args, and passes it up to `super`, and the superclass assumes 2 (ellipsis) args - a subclass implements doesNotUnderstand...

The only way to avoid this issue would be if we could distinguish whether doesNotUnderstand was called via `performList` / `(selector, *args)`, or not. But I don't think this is...

OK, I think we have to live with two versions of doesNotUnderstand. I have two suggestions concerning naming. 1. keeping the smalltalk flavour of our language, let's call the new...

But I am still thinking about how we could just do it with `doesNotUnderstand`. If you have an idea, drop it in!

> What do you think about making the default method be `doesNotUnderstandWithKeys`, and only if it doesn't exist, will `doesNotUnderstand` be attempted? Meaning, both the child method will be called...

Here is a test: https://gist.github.com/telephon/0e31961dfd1599ddc3ce4e158e6e3dcb

I have tried to find a way to have only one call back from the backend, but this doesn't work in the delegation logic as we would like it to....

I am not sure I understand. All this seems to be a bit opaque. Maybe for a start, the backend should only call `doesNotUnderstandAbout` in a class that has it...