about ImageJ extensibility

[Airen Zaldívar Peraza]

Dear ImageJ developers, I would like to request for future versions of
ImageJ that you replace private and package methods, if possible, for
protected methods. This way inheritance would be much more easy. We have
extended ImageJ creating our own ImageCanvas, ImageWindow, etc and we are
very happy with the results, since we can use zoom, move, filters, etc,
with very little customization. Only that sometimes we cannot reuse code
because of the visibility of the parent attributes and/or methods. Code
sometimes is not very extensible.
Best regards Airen

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

On Jul 13, 2015, at 09:55, Airen Zaldívar Peraza wrote:

> Dear ImageJ developers, I would like to request for future versions of
> ImageJ that you replace private and package methods, if possible, for
> protected methods. This way inheritance would be much more easy. We have
> extended ImageJ creating our own ImageCanvas, ImageWindow, etc and we are
> very happy with the results, since we can use zoom, move, filters, etc,
> with very little customization. Only that sometimes we cannot reuse code
> because of the visibility of the parent attributes and/or methods. Code
> sometimes is not very extensible.
> Best regards Airen

Hi Airen,

in my view it is not so simple to declare all 'internal' methods and variables protected:  When changing the code (for bug fixes or improvements), some methods and class variables may disappear or do something different.

If you suggest a few methods that you want protected instead of private, and they are nothing that may change in the foreseeable future, Wayne might do it (of course, I can't speak for him).

So far my 3 cents,

Michael

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Airen,

> I would like to request for future versions of ImageJ that you replace
> private and package methods, if possible, for protected methods.

API design must be carefully considered, to provide easy access to as much
functionality as possible, while simultaneously avoiding breakages of
backwards compatibility whenever possible.

See this article on the ImageJ wiki for details:
http://imagej.net/Coding_style#Private_over_protected_fields_and_methods

And in particular, see the linked post on StackOverflow:
http://stackoverflow.com/a/3631338

As an aside, one of the primary goals of the ImageJ2 project (
http://imagej.net/ImageJ2) is to build on ImageJ's extensibility even
further, providing rich, modular APIs as a foundation upon which many sorts
of plugins can be built [1]. If you are building major components on top of
ImageJ, then I would encourage you to take a look at ImageJ2, which tries
very hard to maintain a separation of concerns conducive to such projects
[2].

Regards,
Curtis

[1] http://imagej.net/Extensibility
[2] http://imagej.net/Architecture

On Mon, Jul 13, 2015 at 10:09 AM, Michael Schmid <[hidden email]>
wrote:

> On Jul 13, 2015, at 09:55, Airen Zaldívar Peraza wrote:
>
> > Dear ImageJ developers, I would like to request for future versions of
> > ImageJ that you replace private and package methods, if possible, for
> > protected methods. This way inheritance would be much more easy. We have
> > extended ImageJ creating our own ImageCanvas, ImageWindow, etc and we are
> > very happy with the results, since we can use zoom, move, filters, etc,
> > with very little customization. Only that sometimes we cannot reuse code
> > because of the visibility of the parent attributes and/or methods. Code
> > sometimes is not very extensible.
> > Best regards Airen
>
> Hi Airen,
>
> in my view it is not so simple to declare all 'internal' methods and
> variables protected:  When changing the code (for bug fixes or
> improvements), some methods and class variables may disappear or do
> something different.
>
> If you suggest a few methods that you want protected instead of private,
> and they are nothing that may change in the foreseeable future, Wayne might
> do it (of course, I can't speak for him).
>
> So far my 3 cents,
>
> Michael
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html