Re: [AD] rename path functions?

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2009-05-09, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> We could make them an exception from the API naming, like the ustr
> functions - but I think it's less justified. My suggestion would be
> (entries marked with * are more than just swapped words):
> 
>       * al_path_append al_append_to_path (*)
>       * al_path_clone al_clone_path
>       * al_path_concat al_join_pathes (*)
>       * al_path_create al_create_path
>       * al_path_create_dir al_create_path_dir
>       * al_path_drop_tail al_drop_path_tail
>       * al_path_exists al_is_path_present (*)
>       * al_path_free al_free_path
>       * al_path_get_basename al_get_path_basename
>       * al_path_get_drive al_get_path_drive
>       * al_path_get_extension al_get_path_extension
>       * al_path_get_filename al_get_path_filename
>       * al_path_index al_get_path_component (*)
>       * al_path_insert al_insert_into_path (*)
>       * al_path_make_absolute al_make_path_absolute
>       * al_path_make_canonical al_make_path_canonical
>       * al_path_num_components al_get_path_length (*)
>       * al_path_remove al_remove_from_path (*)
>       * al_path_replace al_replace_path_component (*)
>       * al_path_set_drive al_set_path_drive
>       * al_path_set_filename al_set_path_filename
>       * al_path_set_extension al_set_path_extension
>       * al_path_tail al_get_path_tail
> 
> And finally:
> 
>       * al_path_to_string

Here are my modifications of your suggestions.

These can be more consistent:

        * al_path_append al_append_path_component (*)
        * al_path_insert al_insert_path_component (*)
        * al_path_num_components al_get_path_num_components (*)
        * al_path_remove al_remove_path_component (*)

al_get_path_length seems very ambiguous.

This one was spelt wrong:

        * al_path_concat al_join_paths (*)

al_path_create_dir() was always unclear to me, like it would call
mkdir() or something.  Maybe one of these:

        * al_path_create_dir al_create_path_for_dir
        * al_path_create_dir al_create_path_no_filename

The _tail functions might not be worth keeping.  Originally I imagined
an ALLEGRO_PATH to be just an array of strings separated by the
directory separator.  The tail of an ALLEGRO_PATH would be the last part
before the final slash, i.e. the filename.  Thomas separated the
filename from the directory components and introduced negative indices
into the functions that take them, so I think the "tail" functions
aren't as useful as they might have been.

> I can only think of long names for it when following the naming
> convention:
> 
> al_convert_path_to_string
> al_get_path_as_string
> al_get_string_from_path
> 
> So maybe for this one we should follow the al_ustr naming and have:
> 
> al_path_cstr
> 
> It's short, and it makes the semantics clearer than the names above, as
> it behaves just like al_cstr (the returned string is valid as long as
> the underlying ALLEGRO_PATH exists and is not modified).

Okay by me, although al_path_to_string() sounds immediately obvious.

al_cstr() is only named like that because I guessed that it would be too
common to name al_ustr_to_string().

Peter