Re: [Yetanotherclib-devel] Library future.

[Jeffrey B. <je...@e-...>]

Hello.

There is an existing code base, which is readily usable and functional, so starting over is not the best thing to do.  The code that I usually work with, the list and the parsing routines, provide great utility and convenience for developers who decide to use the library.  If people want to use STL, they would program in C++, so differences from STL are not a deficiency.  The key is to have the functionality provided by STL, and any proceeding extensions and convenience routines.  For now, it may be best to implement the new containers alongside existing code.  There is nothing wrong with having duplicate functionality for the time being, as such is better than the absense of functionality that a rewrite can create.  

Revision of calling conventions, in an effort to unify the library, is a good idea.  Since C does not have a namespace feature, a prefix to all globals must serve this purpose, else the standard C namespace can become polluted due to the rather common names currently utilized by this project.  

I will write up a draft HACKING file, defining the coding and calling conventions, based on what you have proposed.  Long method names are usually not a problem, as a method name should give a distinct idea as to its purpose.  The GNU coding standards contain many good ideas in good design.  *This may not be the best name for the parameter of the container methods, as it has no meaning outside of an object oriented language.  Until (if such may be the case) an object system is put in place, the currently used *l should be fine and correct.  

Maybe container structures should contain function pointers, so that one may do l->size(), or l->sort().  In this context the *This parameter would come into use (perhaps better spelled *this as only constants should contain capitals).   

I am interested in working on a string container.  I can integrate my parsing code into this.  

A doubly linked list, as such that is currently implemented, and the ability to insert at the beginning or end make the deque unnecessary.  Queue functions should be added to list.c:  yacl_list_push(struct list *l, void *data, size_t size) and yacl_list_pop(struct list *l).  These functions and functions with the _head suffix should be added.  The push functions would be aliases for the addElem functions.  The pop functions would return the data of the element at the end or beginning of the list and delete the element.  

I have already made the conversion to the ChangeLog.  

The library also works on NetBSD, as I have a computer that runs it.  

Since all currently appears to be in good condition in the library as it is, as far as usability goes, it may be a good idea to put out a 0.2.0 release.

Thanks for your time.

Regards,
Jeffrey Bedard