move a lot of the extraneous functions / attributes out of the core ExtensionArray class and into a better home

Can you expand on this? Early on when implementing EAs there was an idea that it could be implemented in terms of a small number of primitives (so the EA namespace could stay small) but that idea didn't pan out.

Yea I am referring to anything that is a method on the ExtensionArray but that is not documented as part of the interface. _values_for_json, _get_repr_footer, etc... work when you use structural typing instead of nominal typing you'd have to re-implement those (see the test case)

So is the suggestion to move those things out of the EA namespace or just to document them as required?

This Protocol approach seems to make it difficult to implement default-but-overridable implementations for things.

Yea not sure yet how to best move things. Maybe that would require something like ExtensionArrayDefaultOpsMixin?

Yea not sure yet how to best move things. Maybe that would require something like ExtensionArrayDefaultOpsMixin?

This seems like a lot of effort to reinvent the idea of a subclass. Is there any evidence that this is a pain point for 3rd parties?

I am not aware of an existing library asking for this. It would be a new feature for a library that in the future may want to implement a class in an extension without having to interact heavily with the Python runtime

Closing for now - may revisit later