Future of EE_Fieldtype class

I don’t have a concrete answer, but a very likely answer is: nothing.

Some of that default behavior does not need to live in a parent class, it can be handled elsewhere. Other things, like install and uninstall, should not be per add-on component at all. It’s an early-v2 relic, in v3 you install the whole add-on as one, and the code should reflect that. Other carry-overs include things like everything still declaring its own versions. The addon.setup file has a single version that should be used everywhere.

For fieldtypes specifically, I would like to see them encapsulate and expose their own data better. The current functional programming inspired approach works well for data stored on the channel data table, but it’s a little finicky when dealing with data in your own tables. For example, you can’t really access grid or relationship data through the ChannelEntry model; all you can get is rendered data.