Make generated code better match Go conventions, and improve usage ergonomics

[thomaspurchas]

The current generated go code has a couple of quirks in it what makes it more difficult to work with than it needs to be. Two primary culprits are:

All fields with structs are always pointers to structs, rather than concrete structs

When providing a API interface to a dataset (such as a Restful API), it's normal for optional fields to be pointers, and non-optional fields to concrete types, including structs. This approach minimises the number of nil checks people have to do, and generally Go discourages the usage of pointers unless they're actually needed because you want to share a value.

Making every struct value in the generated code is very unergonomic, as it either requires nil checks littered at every level of your code that interacts with these structs, or (more likely) people don't bother with the nil checks, relying on Pkl to enforce the existence of values. However that approach means there's no indication as to what might break if a non-optional field is later make optional. By following go conventions, this change will result in build failures, rather the current runtime failures.

Structs sometimes have an Impl postfix and sometimes don't

Currently the generated code will create an Interface for every open or abstract Pkl class, and name the associated struct SomthingImpl. There's nothing inherently wrong with this approach, but it does make it unnecessarily painful to change a Pkl class from closed to open, or visa-versa.

If a class is made open then the existing Go struct will have Impl appended to its name, and its existing name will become an interface, breaking all existing code that previously referenced the original struct. There's no need for this breakage as there is also a Go convention to prefix interfaces with I (although frowned upon, but no more than appending Impl to structs). Using the interface prefix, rather than the struct postfix, means that the names of structs remains static regardless of the modifiers on the Pkl class. Thus when a Pkl class is made open a new ISomething interface is created, but the existing Somthing struct remains untouched, preventing unnecessary breakage.

Example of changes

These changes are probably best viewed by looking at the diffs of the snippet test outputs, but here's an example that demonstrates most the resulting changes to the generated go code.

Original:

type Person interface {
	Being

	GetBike() *Bike

	GetFirstName() *uint16

	GetLastName() map[string]*uint32

	GetThings() map[int]struct{}
}

var _ Person = (*PersonImpl)(nil)

// A Person!
type PersonImpl struct {
	IsAlive bool `pkl:"isAlive"`

	Bike *Bike `pkl:"bike"`

	// The person's first name
	FirstName *uint16 `pkl:"firstName"`

	// The person's last name
	LastName map[string]*uint32 `pkl:"lastName"`

	Things map[int]struct{} `pkl:"things"`
}

New:

type IPerson interface { <----- Interface now has I prefix
	IBeing

	GetBike() Bike

	GetFirstName() *uint16

	GetLastName() map[string]*uint32

	GetThings() map[int]struct{}
}

var _ IPerson = Person{}

// A Person!
type Person struct { <------ Person no longer has Impl postfix
	IsAlive bool `pkl:"isAlive"`
        
	Bike Bike `pkl:"bike"` <------ Bike is no longer a pointer

	// The person's first name
	FirstName *uint16 `pkl:"firstName"`

	// The person's last name
	LastName map[string]*uint32 `pkl:"lastName"`

	Things map[int]struct{} `pkl:"things"`
}

[bioball]

Per our conversation: please split this into two PRs. Thanks!

[thomaspurchas]

@bioball #92 covers the changes to structs and pointers, but remove the naming changes to interfaces etc. I'll probably wait until we've got that merged before creating an interface naming PR because some of the changes in the PR will make it much easier to make the interface naming change later.

[bioball]

Sounds good! Will take a look.