Re: [AD] Clarifying and revising filesystem API

[Peter Wang <novalazy@xxxxxxxxxx>]

2009/4/16 Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>:
> On Wed April 15 2009, Peter Wang wrote:
>> 2009/4/16 Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>:
>> >> % File system hooks
>> >>
>> >> # File system types
>> >>
>> >> ## API: ALLEGRO_FILE_HANDLE
>> >
>> > No. Its not a file. Its an entry. This will just confuse people. Its
>> > generic for a reason.
>>
>> That's why I refrained from ALLEGRO_FILE, but apparently the extra
>> "handle" isn't enough.  I don't mind ALLEGRO_FS_ENTRY too much
>> (it's unfortunate that "filesystem" is so long).
>>
>> But _these_ unqualified names really bother me:
>>
>>     al_get_entry_size, etc.
>>     al_is_present, etc.
>>
>> They could be dealing with absolutely anything.
>
> Indeed. I was never happy with al_is_present. Chatted with people a few times
> about it. it used to be called al_fs_exists (or just exists() in a4).

al_fs_entry_exists() would be ok.  exists() was sinful.

>> Could you live with:
>>
>>     al_get_fs_entry_size, etc.
>>     al_fs_entry_is_present, etc.
>
> I thought that would end up being too long. I don't _mind_ it, but I think
> some of these names are just too long. I tried to leave out the fs when ever
> possible. we could go back to "exists" for the second function to make it a
> little shorter: al_fs_entry_exists, but that might not be quite clear enough,
> I dunno.

These functions won't be used very often.

> But I thought we were trying to get rid of the prefixes?

I think, in general, we're trying to integrate the subject into the
function name smoothly, yet retain enough of the subject or object to
keep the name in context.

That said, I don't see a prefix here.  We'd have to be naming the
majority of the functions al_fs_entry_* for that.

Peter