Private interfaces hinder downstream usability

[kylecarow]

IMO the functionality of this crate would be greatly enhanced by allowing downstream users access to currently private interfaces.

For example, there is useful image information currently hidden within the Decoder's image field. It seems to me that this is an easy fix - simply make Decoder.image public, along with the Image struct and any necessary nested fields. I gather from other issues there isn't much bandwidth to work on this crate, but this would be a very simple fix that would greatly benefit downstream users. Is there some reasoning to keeping the interface semi-private? Should I draft up a PR to do this?

A couple more opinions:

• There would be use in exposing the type of the underlying image data to users, rather than having it only available after generating a DecodingResult.
• The Decoder::image() accessor method should be removed entirely, especially if Decoder.image is made pub. Or maybe I'm missing some reason for its existence?

[fintelia]

This is a fair point!

The reason for making the interfaces private initially was so that I could do a bunch of internal refactoring without having to design/think about what the public API should be for it. But since then I've never had a chance to actually do the design work to figure out a good public API.

The reason for making the Decoder::image() method was to enforce that the Image object was initialized once and then not modified. If the interface is made public, it probably makes sense to enforce that users have only read only access to Image so they can't accidentally corrupt it.