Re: [AD] al_verb_noun

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2009-02-01, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> I spotted a few (new?) cases where the function names seem to deviate  
> from the guidelines:
> 
> al_ustr_new (should be al_create_ustr or al_create_ustring?)
> al_ustr_new_from_buffer
> al_ustr_free
> al_cstr  (al_convert_to_cstring?)
> al_cstr_dup (what's the difference with the previous function?)

al_cstr returns a const char * which shares space with the ALLEGRO_USTR.
al_cstr_dup makes a copy.

> al_ustr_dup (al_duplicate_ustring?)
> 
> etc. for the other string functions. May make sense to wait until they  
> are all implemented (the comments in the file indicate some functions  
> still need to be added).

Only a few to go.

I like the _ustr prefix, but I don't know if I can justify it, so I
won't argue against renaming them *if* we can come up with a set of
succinct, unambiguous names with the usual scheme.

When designing an API, especially little self-contained ones, I just end
up naming functions with "module qualifiers", as you can see in the
internal vector functions, the internal thread functions, the path
functions and now the string functions.  It's *not* al_<object>_<verb>
though.  It just happens that the module qualifier is usually a noun :)

> also (from utf8.h),
> 
> struct ALLEGRO_USTR_INFO {
>     /* This struct needs to be at least as big as struct  
> _al_tagbstring. */
>     int __pad[4];
> };
> 
> might I suggest that in light of that comment this should then be
> struct ALLEGRO_USTR_INFO {
>     struct _al_tagbstring __dummy;
> };
> or something similar? Or am I missing something?

The idea is to not expose the definition of struct _al_tagbstring, which
is an implementation detail.

Peter





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/