Removing the ojph_ prefix.

[aous72]

@chafey
It was suggested to me before by you, and perhaps others, that I remove the ojph_ prefix from the files. It makes everything shorter.
It is easy to do.
Are you still of this opinion?

Thank you.

[chafey]

Yes, this would be a good improvement.

[thewtex]

Hi @aous72 @chafey ,

Thank you for your wonderful work 🙏

Can we please keep the ojph_ prefix to avoid ambiguity with similar files?

[chafey]

Using filenames to avoid ambiguity is not scalable and is not a best practice. Is there a reason you can't use directory names to remove ambiguity ?

…

On Tue, Aug 8, 2023 at 10:09 AM Matt McCormick ***@***.***> wrote: Hi @aous72 <https://github.com/aous72> @chafey <https://github.com/chafey> , Thank you for your wonderful work 🙏 Can we please keep the ojph_ prefix to avoid ambiguity with similar files? — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJVXWWED4POASXS54JDPRDXUJJCFANCNFSM6AAAAAATGA6NYA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aous72]

Good to hear from you @thewtex, and thank you @chafey.

[thewtex]

I am not sure why a prefix is considered not scalable? We just have a prefix in the file names. A prefix is a best practice and it is used by many libraries including, for example, JPEG, TIFF, and PNG to name a few. Commonly headers are included by name, without including their directory, and the prefix avoids ambiguity. Headers are ideally portable and not tied to a directory structure. For example, the directory structure of headers in the OpenJPH source tree and install tree are different, and one may want to be able to build against one or the other. Or, they may want to vendor the headers in a different directory layout.

[aous72]

I would not mind keeping the prefix.
Perhaps, I can remove the prefix from internal files, and keep it for interface files (i.e., those included by other applications).