Speaking of development practices, I've recently noticed that there's a bit of heterogeneity in the API, with some parts being object-oriented in style and others (most) being functional, which is my preference. Do we want to emphasise that this is the preferred style?
The functional style is imo the preferred style, especially for raw image processing functionality, which only takes some image and produces some output. But there are parts where object-oriented style makes a lot of sense. I only know of the following excessive cases: - skimage.transform.GeometricTransforms - skimage.measure.fit.*Models - skimage.viewer And in some places internally, mostly where actually appropriate. But only the interface is relevant in my opinion. I can only speak for the estimation functionality in skimage, where objects help a lot to make a sane implementation - a purely functional interface would be horribly complicated. Maybe it’s easier to keep track of the status of the discussion for everyone with a new PR: https://github.com/scikit-image/scikit-image-paper/pull/3 Please, raise your voice for more ideas and if you are volunteering for a section :-)
Is there currently a preferred way to cite scikit image while this paper is in the works? On Wed, Nov 20, 2013 at 9:03 AM, Johannes Schönberger <jsch@demuc.de> wrote:
Speaking of development practices, I've recently noticed that there's a bit of heterogeneity in the API, with some parts being object-oriented in style and others (most) being functional, which is my preference. Do we want to emphasise that this is the preferred style?
The functional style is imo the preferred style, especially for raw image processing functionality, which only takes some image and produces some output.
But there are parts where object-oriented style makes a lot of sense. I only know of the following excessive cases:
- skimage.transform.GeometricTransforms - skimage.measure.fit.*Models - skimage.viewer
And in some places internally, mostly where actually appropriate. But only the interface is relevant in my opinion.
I can only speak for the estimation functionality in skimage, where objects help a lot to make a sane implementation - a purely functional interface would be horribly complicated.
Maybe it’s easier to keep track of the status of the discussion for everyone with a new PR: https://github.com/scikit-image/scikit-image-paper/pull/3
Please, raise your voice for more ideas and if you are volunteering for a section :-)
-- You received this message because you are subscribed to a topic in the Google Groups "scikit-image" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/scikit-image/ReKcHGSaATU/unsubscribe. To unsubscribe from this group and all of its topics, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
participants (2)
-
Adam Hughes -
Johannes Schönberger