Refactor step3codegen package (mainly TypeGenerator)

[myhau]

Task

Related to #24.

Description

Note

I could do much more here, but I've already proved to myself that these big-bang refactorings turn into never-ending rabbit holes (with lots of merge conflicts). We need to keep these PRs small and focused.

Main changes

1.

Refactor TypeGenerator:

• extract SetterGenerator interface so that:
  • per-generator logic (for setters) can have its own class, for example:
    

    pulumi-kotlin/src/main/kotlin/com/virtuslab/pulumikotlin/codegen/step3codegen/types/setters/BasicGenerator.kt

    Lines 10 to 11 in f936b32

    	object BasicGenerator : SetterGenerator {
    	override fun generate(setter: Setter): Iterable<FunSpec> {

  • new setters (e.g. enum) can be added without changing existing code
• divide big method into multiple well-named methods

2.

Add comments to some methods that return TypeName or FunSpec. Example:

pulumi-kotlin/src/main/kotlin/com/virtuslab/pulumikotlin/codegen/step3codegen/KotlinPoetPatterns.kt

Lines 24 to 32 in f936b32

	/**
	* Example output:
	*
	* ```
	* List<suspend InnerType.() -> Unit>
	* ```
	*/
	fun listOfLambdas(innerType: TypeName): TypeName =
	LIST.parameterizedBy(builderLambda(innerType))

3.

Create KotlinPoetExtensions.kt files with extension methods that could increase readability (e.g. addImports) and reduce noise in generators' code. Example:

pulumi-kotlin/src/main/kotlin/com/virtuslab/pulumikotlin/codegen/step3codegen/KotlinPoetExtensions.kt

Lines 11 to 16 in f936b32

	object KotlinPoetExtensions {
	fun FileSpec.Builder.addTypes(vararg typeSpecs: TypeSpec) =
	addTypes(typeSpecs.toList())
	fun TypeSpec.Builder.addFunctions(vararg funSpecs: FunSpec) =
	addFunctions(funSpecs.toList())

4.

Add new methods and rename existing methods in MoreTypes. For example:

pulumi-kotlin/src/main/kotlin/com/virtuslab/pulumikotlin/codegen/step2intermediate/MoreTypes.kt

Lines 12 to 22 in 8616eb8

	object MoreTypes {
	object Kotlin {
	object Pulumi {
	fun toJavaMethod(): MemberName {
	return MemberName("com.pulumi.kotlin", "toJava")
	}
	fun pulumiDslMarkerAnnotation(): ClassName {
	return ClassName("com.pulumi.kotlin", "PulumiTagMarker")
	}

We can use something::class.asTypeName(), but I'm not sure this will be possible in the future (#41), so I'd prefer having all these "hardcoded" cases in MoreTypes for now.

(Edit) Clarification from: #72 (comment)

I turned all ClassName(package, name) into Type::class.asClassName(), but I'd still prefer to keep them all (MemberName and ClassName factory methods, like applySuspendExtensionMethod) in this class (MoreTypes) to ease potential refactorings and have opportunity to give them good names.

(MoreTypes should probably be named differently and placed in step3codegen package.)

Merging this PR

I created main-2022-10-16-all-pr-merge branch and cherry-picked existing PRs there to minimize the risk of conflicts, so this can be merged only after these are merged:

• Fix index namespace issues #54
• Add support for asset and archive #55
• Remove UseCharacteristic class and improve things around NamingFlags #70
• Improve readability by using multi-line string in e2e tests #69
• Replace Supress in SchemaModel.PropertyType with SerialName (per value) #68

[jplewa]

Just some minor stuff. Also, you need to get rebased.

[jplewa]

@myhau

We can use something::class.asTypeName(), but I'm not sure this will be possible in the future (#41), so I'd prefer having all these "hardcoded" cases in MoreTypes for now.

I think we could still attach that library as a dependency here, no?

[myhau]

@myhau

We can use something::class.asTypeName(), but I'm not sure this will be possible in the future (#41), so I'd prefer having all these "hardcoded" cases in MoreTypes for now.

I think we could still attach that library as a dependency here, no?

Yes, I just turned all ClassName(package, name) into Type::class.asClassName(). I'd still prefer to keep them all (MemberName and ClassName factory methods, like applySuspendExtensionMethod) in this class to ease potential refactorings and have opportunity to give them good names.