fix name mismatch: item vs context

[dukesook]

Many of the function declarations in heif_items.h didn't match EXACTLY to their implementations in heif_items.cc, causing runtime errors: 'undefined reference to function`

heif_context_get_item_data() had two different implementations. I'm not sure if both are needed.

[farindk]

Sorry, it should be the other way round. It should mimic an object oriented programming style. The first parameter is the object. Thus, if the first argument is a heif_context, the function name should also start with heif_context_.

[farindk]

I'll do the fix.

[farindk]

Ok the problem is that the heif_items.h file was already present in the v1.18.2 release. That means we cannot change the names without breaking the binary compatibility.

I would propose that we rename it, but also keep the old names as deprecated duplicates.

[farindk]

No, we take your PR. It makes more sense. The heif_context*, heif_item_id pair in the function arguments are logically like a item object (we don't have an heif_item). In that sense, the naming with heif_item_* is consistent.

[farindk]

@fancycode Does that work in the packaging? In v1.18.2, we had public API functions named heif_item_*foo* in heif_items.h, but these were not implemented because the functions had the different prefix heif_context_*foo* in heif_items.cc (without any public API declaration).

Now, for v1.19.0, the implementation will use the correct function name from the header (heif_item_*foo*).

[fancycode]

@farindk that should not be a problem. As there was a mismatch between the (exported through LIBHEIF_API) name in the header and the name in the implementation, the implementation was not exported and thus was not a public symbol in the resulting library. If this is now fixed for the next version, the correct symbols will be exported and will be available to consumers of the API starting with the next version.