Currently, AIJ make no separation between API surface and internals, making macros and plugins that depend on AIJ fragile to its updates, as any change in behavior or method signature could cause them to break. IJ's apparent solution to this is restricting macros to public static members, a restriction since removed by us to deal with lack of API surface in AIJ. AIJ internals are also largely undocumented, serving as a barrier to macro and plugin development, in addition to the limitation of only allowing static calls.
Creating a unified, mid- to long-term stable, and well documented API would greatly aid macro and plugin developers.
Proposal
Create a unified, versioned package, such as com.astroimagej.api.v1, to contain all of the API
Breaking changes will require a vN+1 package, allowing for the vN package to remain for some time after its replacement is made
Provide a version number for the API, separate from AIJ's, to allow plugins/macros to make decisions on if/how they run
Provide a way to check and log usage of deprecated API members
Provide static members that are capable of accessing instance members, greatly increasing the amount that macros can do
Nongoals
Removal of the ability for macros/plugins to touch AIJ internals, they will do so will the knowledge that an AIJ update may break the macro/plugin, possibly without warning
This needs to be communicated with plugin/macro developers, and API additions will largely depend on what they need.
This should precede #27.
Currently, AIJ make no separation between API surface and internals, making macros and plugins that depend on AIJ fragile to its updates, as any change in behavior or method signature could cause them to break. IJ's apparent solution to this is restricting macros to
public staticmembers, a restriction since removed by us to deal with lack of API surface in AIJ. AIJ internals are also largely undocumented, serving as a barrier to macro and plugin development, in addition to the limitation of only allowingstaticcalls.Creating a unified, mid- to long-term stable, and well documented API would greatly aid macro and plugin developers.
Proposal
com.astroimagej.api.v1, to contain all of the APIvN+1package, allowing for thevNpackage to remain for some time after its replacement is madestaticmembers that are capable of accessinginstancemembers, greatly increasing the amount that macros can doNongoals
This needs to be communicated with plugin/macro developers, and API additions will largely depend on what they need.