Typed extensions experiment

[alexykot]

just an example, not to be merged

Here's how extensions can be typed enough to be explicitly comparable, and still permit arbitrary custom extensions.

[EliCDavis]

I think this is overall a good refactor to have. You're welcome to include it in your other PR or keep it in this one. your choice!

[EliCDavis]

For people who are creating a bunch of extensions, this Equal might become annoying to implement.

In the past I've been thrown weird extension I need to support for one off engagements that end up having a bunch of random extensions (see OWT WFF GLTF extensions).

I think it might be worth moving this into it's own interface. Then the GLTF writer checks if the extension implements this interface, and if so, use the equals function. Else it only uses the pointer equivalence

type EquatableExtension interface {
	Extension
	Equal(other Extension) bool
}

[alexykot]

Yes, this could be an option. Although this becomes quite an obscure feature that is non-trivial to even find. Clarity and self-explanation of the API is valuable as well, and what would be the right tradeoff here is unclear to me.

Maybe adding comments around this interface explaining what it does would be sufficient.
Or the user could always do something like if they're in a rush 🙂:

func (my MyExt) Equal(other Extension) bool {
    return my == other
}

Either way - I don't feel informed enough to suggest the right tradeoff here. I have only one case - my own, and that's not enough to decide the interface for all users, at least not in the situation where no obvious optimal solution exists.

[alexykot]

Nah, thanks, I'll pass on this one 🙂

I have no direct need for this one at the moment, and my concerns are solved with #51. This is just a suggestion.
Maybe some other time when I'll have a need in this kind of thing on my end.

[alexykot]

I mean - I didn't intend to actually implement this one, this was more of a talking point than an design draft.

I've closed it now.