Converting either to a map[string]interface{} or a slice []interface{} was my previous implementation, the only drawback is that it looses the order of the associative array.

For packed arrays you have direct access to the slice via array.Values. Just for associative arrays you can't have a map that also retains the order, it has to be some kind of ordered map implementation.

Easiest solution is to just ditch the order, i can reset it back to that implementation if the general consensus is that order doesn't matter that much.

Maybe it could be nice to support ordered associative arrays, and typical unordered Go maps?

Could do it like this?

type OrderedMap struct {
    keys []string
    data map[string]interface{}
}

It still allows ordered access by iterating over keys, and O(1) lookup by key via the map.

For full context, I'm also working on an implementation that changes this whole thing up. Right now, it basically copy-pastas your implementation into a new file. Instead of doing that, the implementation I'm working on would allow you to write code like this:

//export_php:function foo(string $value): void
func foo(val string) {}

Then in the generated file, instead of reusing the same package name and copy-pasting your implementation, it will generate a new package ("ext" by default):

package ext

//export
func go_foo(value *C.zend_string) {
  foo(frankenphp.GoString(value))
}

This makes it so that:

1. It doesn't accidentally miss related functions in the same file
2. Allows for more idiomatic code
3. Doesn't even necessarily have to be in the same file (it can scan the whole project)

So, it is unlikely anyone will ever use our internal types directly using the generator. That's why I said having direct access to the maps/slices will probably be better.

Yeah we can also ditch the types completely and just have something like

PHPAssociativeArray(entries map[string]interface{}, order []string) unsafe.Pointer

PHPPackedArray(values []interface{}) unsafe.Pointer

GoAssociativeArray(phpArray unsafe.Pointer, ordered bool) (map[string]interface{}, []string)

GoPackedArray(phpArray unsafe.Pointer) []interface{}

Since we expect the type (*C.zval), it would be great to just accept/return that type instead of unsafe.Pointer. I already got bit a couple of times because I changed my type, but not the function to transform it, and unsafe.Pointer doesn't cause a compilation error.

cgo types cannot be exported/used by another package. This causes runtime issues, we already got beat by that.

What we may do however, is creating to dedicated aliases of unsafe.Pointer (to be tested, but it should work).

Alright, there are now multiple ways to convert an array to cover all 3 cases with direct access to the primitives on the go side:

• ordered associative
• unordered associative
• packed

type AssociativeArray struct {
	Map   map[string]interface{}
	Order []string
}
func GoAssociativeArray(arr unsafe.Pointer, ordered bool) (AssociativeArray, error)
func PHPAssociativeArray(arr AssociativeArray) unsafe.Pointer

type PackedArray = []interface{}
func GoPackedArray(arr unsafe.Pointer) (PackedArray, error)
func PHPPackedArray(arr PackedArray) unsafe.Pointer

I wonder if having GoAssociativeArray and, as an optimization, GoUnorderedAssociativeArray (or just GoMap) wouldn't be a better (more explicit) API than passing an extra boolean parameter. WDYT?

Yeah we can do that as well 👍 . We could also do something like this:

func GoMap(unsafe.Pointer) map[string]any
func PHPMap(map[string]any) unsafe.Pointer

func GoSlice(unsafe.Pointer) []any
func PHPSlice([]any) unsafe.Pointer

func GoArray(unsafe.Pointer) AssociativeArray
func PHPArray(AssociativeArray) unsafe.Pointer

LGTM! I would just go for PHPPackedArray instead of PHPSlice and maybe PHPAssociativeArray instead of PHPArray to disambiguate and keep with "official" PHP terms.

Thank you!!