[ 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:
> > > 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.
Look at the memfile addon, is that a failing of design? how about Allegro GL in
a4? They both need internals. How would you suggest the memfile addon be fixed
to not depend on any internals, while still providing a new type of file
handle?
> 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.
I disagree. The hook vtables should not be globally public.
> > > 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.
If you want to bring back the functions to set and get the vtable, they aren't
stuck. I just figured it looked odd against the other bare vtables in allegro
so I decided to remove them (even though they should probably all use them...)
And changing a struct items name, will not break bic.
> Peter
>
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx