[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On January 22, 2009, Peter Wang wrote:
> On 2009-01-22, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > On January 22, 2009, Peter Wang wrote:
> > > On 2009-01-22, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > On January 22, 2009, Peter Wang wrote:
> > > > > On 2009-01-22, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > > > On January 22, 2009, Peter Wang wrote:
> > > > > > > On 2009-01-21, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > Also, can I delete _al_fs_hook_create() etc.? They seem to only
> > > > > > > be used in one place each and make the code harder to read.
> > > > > >
> > > > > > I created them so in the future if we have to change the
> > > > > > implementation of vtable names, the code that uses them doesn't
> > > > > > have to change.
> > > > >
> > > > > That would only be confusing if the macro names don't match the
> > > > > vtable names.
> > > >
> > > > They do now, somewhat. Who knows what changes might need to be made
> > > > behind the scenes later on. Right now if a vtable name changes, only
> > > > the aintern_fshook.h file needs changed. Once addons start needing
> > > > that header, the macros may start to be used in more places, infact,
> > > > the stdio code should probably use them, just in case one or more of
> > > > the vtable methods was swapped out for some reason, right now, it
> > > > will ignore the handle's vtable once its in its own code.
> > >
> > > Sorry, I didn't understand that.
> >
> > Do you mean to say you don't understand what I said there, or you didn't
> > catch on before...
>
> I didn't understand what you said then. The sentence with six commas.
>
> What would addons need that header? Isn't it meant to be internal?
Well, it was supposed to be initially. but addons are permitted to use them
are they not?
> What do you mean by vtable methods being swapped out? And why?
If you want to alter the behavior of a single file handle temporarily, its kind
of like allegro gl swapping vtable methods after its created objects. Im not
sure it'd be something entirely common though.
> Why will "it" (fshook_stdio.c?) ignore the handle's vtable?
Once a fshook_stdio function is called, if it needs to call other fshook_stdio
functions, it calls them directly, instead of through the vtable, as it
probably should do.
> And why would the macros prevent that, as opposed to writing
> handle->vtable->method explicitly?
That wasn't the point there. Using the macro instead of not using the vtable
or macro was the issue.
Now, using the macro instead of the vtable directly lets EVERYONE who ever
uses the macros to keep using them, regardless of what vtable pointers are
called, or if the vtable's arguments order change. The macro can stay the
same. The code that uses them can stay the same. Only functions that implement
the vtable will have to change (and only if the arguments change). It _should_
greatly reduce the number of places changes need to be made in the future
(right now I've kept them updated because I can, once a real release is made,
they'll be stuck, whereas the vtables need not be). Its sort of like adding OO
encapsulation.
If the vtable changes, most changes should only need to be made in the
aintern_fshook.h file. Instead of in fshook.c, and in many places in the stdio
driver, and any future drivers.
>
> Peter
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx