Allow to use non-empty constructor for input types

[olsavmic]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Documented?	no
Fixed tickets	#...
License	MIT

Previous implementation did not allow class with GQL\Input() annotation to have constructor with arguments.

[Vincz]

Hey @olsavmic ! I'm not sure what you are trying to achieve here?
Why we would want to instantiate the class without calling the constructor ?
And why should it be the only option? What if I have initialisation stuff in my constructor?
Can you give me more details ?

[olsavmic]

Hi @Vincz, sure, It should have been a part of the PR, I'm sorry.

What I'm trying to achieve here is this:

Let's assume we have an Input type defined like this:

/**
 * @GQL\Type(name="WebHook")
 */
class WebHookGQLType
{
	/**
	 * @GQL\Field(type="String!")
	 */
	private Uuid $id;

	/**
	 * @GQL\Field(type="String!")
	 */
	private string $url;

	public function __construct(Uuid $id, string $url)
	{
		$this->id = $id;
		$this->url = $url;
	}

	public static function fromWebHook(WebHook $webHook): self
	{
		return new self($webHook->getId(), $webHook->getUrl());
	}

	public function getId(): Uuid
	{
		return $this->id;
	}

	public function getUrl(): string
	{
		return $this->url;
	}

}

This object can be instantiated in two ways:

1. By passing through the GraphQL parser which means it is valid against the schema and constraints and therefore should be in valid state.

2. By calling a constructor which, in this example, instantiates the object into valid state as all the required parameters are set there.

I do not see any reason why I would want to have some logic in an Input object as it's only a data object and no properties from input are set when the default constructor gets called. Perhaps I'm missing something.

Though I definitely prefer having a properly defined constructor that assures me that the object is in valid state and therefore I don't have to look up to the schema to find out what is and what is not required to be set.

I'm not saying that it is the only option, it definitely could be on/off feature based on the configuration which would be OK for me.

Another solution to this problem would be to make the ArgumentsTransformer's private methods either protected OR, if you do not want to allow such inheritance, add an ArgumentsTransformer interface and make the class final.

Right now, we are using the approach showed in this PR and had to copy half of the ArgumentsTransformer just to change this one private method which, as would be expected, resulted in a bug.

Let me know if you find any of the proposed solutions more suitable and I will update the PR accordingly.

[mcg-web]

I'm no sure of this one, instancing some class without constructor can lead to unexpectable behaviors, we should maybe reconsider this change.