Refactor TypeGenerator

[murtukov]

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

This is a draft.

@mcg-web I think the GraphQL configs ($types argument) should be moved away from TypeGeneratorOptions because it's not an option, but actual data the generator works with.

I also kept the constructor in the TypeGeneratorOption cause it ensures the object to be properly initialized. Without a constructor the object can have uninitialized properties, which is not desired:

$options = new TypeGeneratorOptions();
$options->cacheDir = "...";

$myVal = $options->cacheDirMask; // throws an error, property uninitialized

The getCacheDir method was simplified and renamed into getCacheDirOrDefault. The argument is not needed anymore, because if you wanna access the cacheDir without the fallback to default you can simply access it directly: $options->cacheDir

[murtukov]

@mcg-web ok, so now the options cannot be accessed outside of TypeGenerator class, except the ones that are exposed via methods:

• TypeGenerator::getCacheDir()
• TypeGenerator::getCacheDirMask()
• TypeGenerator::getCacheBaseDir()
• TypeGenerator::setCacheBaseDir()

---

What about this?

I think the GraphQL configs ($types argument) should be moved away from TypeGeneratorOptions because it's not an option, but actual data the generator works with.

[mcg-web]

I think the GraphQL configs ($types argument) should be moved away from TypeGeneratorOptions because it's not an option, but actual data the generator works with.

We can indeed inject $types directly in TypeGenerator.