Re: [AD] fshook changes

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


On 2009-01-22, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> On January 22, 2009, Peter Wang wrote:
> >
> > 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?

Preferably not.  If they do, it usually indicates a failing of the design.

In this case, the whole point for the existence of fshooks is so they
can be extended by the user.  That means it should be possible to do
without reaching into internal headers.  So the vtables (or whatever) do
need to be moved out into the public headers, though they don't need to
be included by default.

> > 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.

That's true.

> > 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.

Actually, they *will* be stuck, for ABI compatibility.  If you want to
be able to change the vtables then those macros need to be functions.
But that's what the fshook layer already *is* anyway.

Peter





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