Re: [Mhash-dev] Additional API headers in 0.9.3

[Jonathan D. <im...@ya...>]

Thanks for the comment.

I'll rename the new headers. They are intended to be
standard headers for both mhash and mcrypt, so were
purposely not tied to mhash only, but you are correct
that they need to be differentiated.

The biggest problem with the old system is that the
headers in mhash, mcrypt and between the two, had
multiple definitions of the same concepts, not
necessarily derived the same way, and were not
necessarily the correct definitions anyway. The
next-biggest problem was that the old system was
coarse-grained, exposed a lot of unnecessary
information and was too cluttered to be maintained
correctly.

One possibility is to leave mhash.h in the default
include directory and to place the others into a
subdirectory. Legacy applications won't break, because
mhash.h includes the new headers and therefore can
point to the correct place for them. This would avoid
cluttering the main include directory, which is
overfull as it is.

The essential core, though, is to have a single
standard header, which programs ancient and modern can
call and use without needing any changes to search
paths, while also improving maintainability of the
code and writability of new code using the libraries.
Clean code that, nonetheless, doesn't break any
existing code is all that's really important. How
that's achieved is just an implementation detail.

If you think renaming the files would achieve this the
best, or if you've another idea on how to layer the
code, feel free to submit a patch to the list or to
the sourceforge page. The list is better, as that'll
be seen faster. As mentioned earlier, the new headers
aren't specific to mhash or to hashing, but if you
think they should be given an mhash_ prefix anyway, I
don't see a problem with doing that now and then
deciding if that's to be permanent when getting closer
to the 1.0.0 release.

Again, I appreciate the feedback. I especially
appreciate the fact that you paid attention to what
the release did!

Jonathan Day

--- Michael Schwendt <msc...@gm...> wrote:

> Dear mhash developers,
> 
> previous versions of mhash only put "mhash.h" into
> standard headers search
> path.
> The most recent release, 0.9.3, installs four
> headers: mglobal.h  mhash.h
> mtypes.h
> mutils.h
> 
> This is bad due to several reasons.
> 
> First of all, it pollutes the namespace for header
> files in standard search
> locations
> and bears the risk that installations of mhash
> cannot coexist nicely with
> other
> packages for software development.
> 
> The odds that some other piece of software installs
> header files with the
> name
> mhash.h are low, but names like mtypes.h and
> mutils.h are rather generic. A
> better
> choice would have been to prefix the file names with
> "mhash", like:
> mhash_global.h mhash_types.h mhash_utils.h mhash.h
> 
> Now one can argue whether simply installing them
> into an own directory, say
> /usr/include/mhash/, would fix this. But that would
> be another change to the
> API.
> Because in order to find the header files in that
> non-standard location, it
> might
> be necessary to modify API users' code and either
> make the code include
> <mhash/mhash.h> or add /usr/include/mhash to the
> search list. But any
> added search paths alter the order in which headers
> are searched for in the
> various locations.
> 
> Please reconsider this change in mhash 0.9.3.
> 
> Regards,
> Michael Schwendt
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com