Re: [AD] file interface fopen

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


On 2010-12-18, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> 
> On Sat, Dec 18, 2010 at 5:39 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > ALLEGRO_FS_INTERFACE is public and documented.
> >
> So is ALLEGRO_FILE_INTERFACE... I was just talking about the FS
> process in general, which I haven't looked at.
> 
> > ALLEGRO_FILE is documented as being opaque, but that could be considered
> > a mistake from earlier in the development process.  If we change the
> > documentation, would that solve the problem for you?
> >
> I'm not a big fan of requiring somebody to use struct inheritance, as
> is currently required by the ALLEGRO_FILE_INTERFACE part. Of course,
> that comes down to personal preference, but I find my proposed version
> easier to follow and understand than the current implementation.
> 
> The current fi_fopen + struct inheritance could be considered the
> internal Allegro hook (for physfs and stdio), not meant for public
> usage. The fi_fopen2 could be named something like fi_fopen_f or
> fi_fopen_userdata and be meant for external user code.
> 
> And yes, if something like the above doesn't make its way into
> Allegro, then the ALLEGRO_FILE type must be made public. I think it
> sets a bad precedent to encourage people to dig into the internal
> headers, especially when writing user code. But my preference would be
> to add al_fopen_userdata() and al_get_file_userdata().

That's fine by me.  I would call them:

    ALLEGRO_FILE *al_create_file_handle(ALLEGRO_FILE_INTERFACE *vt,
        void *userdata);
    void *al_get_file_userdata(ALLEGRO_FILE *f);
    void al_destroy_file_handle(ALLEGRO_FILE *f);

The fi_fopen2 method is not required, is it?

I'm releasing RC3 now but we can add this for 5.0.

Peter




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