Approaches to modifying FlowExpressions.Receiver

[Jugal Mistry]

Hi!

After my meeting with Max, We thought of an approach to replace the functionality of receiver class (Approach 3). I don't know if backwards compatibility is absolutely necessary, and I want your suggestion. I have listed the three approaches:

Approach 1:

Make `Receiver` a wrapper around `Expression`

and subsequently the subclasses of `Receiver` will be a wrapper around subclasses of `Reciever` i.e. `MethodCall` will be a wrapper around `MethodCallExpr`

Pros: Least refactoring among all three approaches, and maybe backwards compatibility.

Cons: Less cleaner code and more redundancy.

Approach 2:

Eliminate subclasses of Reciever, and make a generic class of maybe similar name.

```

public class Reciever<T extends Expression> { 

   T currentExpression;

   ... 

}

```

Pros: Lesser Refactoring (Greater than approach 1)

Cons: All of the functionality of each subclass of `T` will have to be included in the same class, Less modular

Approach 3:

Eliminate Receiver, and all of its subclasses with equivalent to 

Pros: Better code clarity

Cons: Most Refactoring and no Backwards Compatibility

Please let me know what will be the best approach. We can also discuss this over a call.

--

Thanks!

Jugal Mistry

[Jugal Mistry]

I am very sorry for this new mail clutter, I forgot to mention details of approach 3

Approach 3:

Remove Reciever and subclasses altogether, and create a utility class with all the methods of Reciever not included in JavaParser API converted to static overloaded methods that take Expression as their parameter.