Re: [AD] file interface fopen

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Sun, Dec 19, 2010 at 5:09 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On 2010-12-19, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
>> If the current interfaces (stdio, etc) used the userdata pointer
>> instead of the struct extension, then there would only need to be a
>> single fi_open hook.
>
> You could make all the fi_* methods take the userdata pointer in
> addition to or instead of the ALLEGRO_FILE argument.
>
I didn't change anything in stdio (etc) just because I didn't want to
make a lot of changes if the general idea wasn't received.

If we make the assumption that all custom file interfaces will contain
user extended data, then it could return that instead:

void *fi_open(const char *filename, const char *mode) { }

Returning NULL would mean that the file could not be opened.
Otherwise, the returned pointer is set to the ->userdata. Thus this
eliminates the need for access to the internals, and it removes the
need for a userdata setter.

And, as you've mentioned, if the user data is passed to all other
functions, you wouldn't need a getter either. [But it would still be
useful for interface-specific methods, like
al_memfile_resize(ALLEGRO_FILE *) or something.]

Also, there's:

ALLEGRO_FILE *al_create_file_handle(ALLEGRO_FILE_INTERFACE *vt,  void
*userdata);

That would just skip the fi_open vt call. It's primary purpose would
be for use by interfaces like memfile. Or is it better for
consistency's sake to have:

al_fopen(const char *path, const char *mode);
al_fopen_vt(ALLEGRO_FILE_INTERFACE *vt, const char *path, const char *mode);
al_create_file_handle(void *userdata);
al_create_file_handle_vt(ALLEGRO_FILE_INTERFACE *vt,  void *userdata);

where the vt versions bypass the default interface?

You also had mentioned "void al_destroy_file_handle(ALLEGRO_FILE
*f);", but I don't see how that differs from al_fclose();

I can make these changes if it sounds good.

--
Matthew Leverton