Added support for arrowfunction

[Luctia]

Closes #19

Thought about adding this:

const assignmentOperatorReplacements = Object.freeze({
  '[^]*': { replacement: 'undefined', mutatorName: 'BodyToUndefined' },
} as const);

Which is a regex that matches everything, because right now, it doesn't matter what's actually in the body.

I rejected that idea, because:

1. There seems to be no way to get the body of the arrow expression as a string, so you cannot perform regular expressions over it;
2. This doesn't seem to be the approach they would want, given that they use functions to determine the type of thing that is in the body, not matching a string or something.

I also thought of using class names as keys, like this:

const assignmentOperatorReplacements = Object.freeze({
  Object: { replacement: 'undefined', mutatorName: 'AnyBodyToUndefined' },
} as const);

The above replacement would allow anything to be set to undefined. Alternatives might be BlockStatement. The idea is that I check the type of body or its contents against the key of the selected level using

return operations.some((op) => body instanceof Object.create(this.context[op].prototype));

However, I could not get this to work. Online threads suggest using this.context or window, both of which are not applicable here (this doesn't mean anything outside of a class and window doesn't work if the application does not run in a browser).

I'm also assuming here that the keys in this array must be strings and that we can't just use class names. Using the second code snippet (the one with Object:), I tried using this in isInMutationLevel:

  if (operations === undefined) {
    return true;
  }
  return operations.some((op: any) => body instanceof op);

Which seems like it should work, because body is always an instance of Object (anything is). It builds, but upon running tests I get the error TypeError: Right-hand side of 'instanceof' is not an object.

I'd be happy to discuss this further, but for now, I simply check whether there is anything in the level at all.

[dvcopae]

In binary cases, where the mutator only has a single operator (this one, BlockStatement, and maybe others) we need to discuss if we should make it a list with a single element (like you did here) or a boolean (like it's done in BlockStatement)

[dvcopae]

In my view, the map object that we have (Object.freeze()) can be seen as a tool, instead of something mandatory that needs to be present in each class. The purpose of this tool is to find the specific sub-operators of an mutator -- I have an ArithmeticOperator, but is this +To- or -To+, etc?

But in this case we either have ArrowFunctions or we don't, so I don't think there is any need to match anything extra because we don't have suboperators.

So, your final approach seems fine to me

[Luctia]

In my view, the map object that we have (Object.freeze()) can be seen as a tool, instead of something mandatory that needs to be present in each class. The purpose of this tool is to find the specific sub-operators of an mutator -- I have an ArithmeticOperator, but is this +To- or -To+, etc?

But in this case we either have ArrowFunctions or we don't, so I don't think there is any need to match anything extra because we don't have suboperators.

So, your final approach seems fine to me

I agree that we should discuss it. Should we just leave this PR until our next meeting?

[dvcopae]

I agree that we should discuss it. Should we just leave this PR until our next meeting?

Yep, we can discuss this at our next meeting.

[Ja4pp]

I agree with all the above comments!