[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On January 23, 2009, Elias Pschernig wrote:
> On Thu, 2009-01-22 at 20:09 -0700, Thomas Fjellstrom wrote:
> > Remember all that talk years ago about what type of types and structs
> > we'd use? We basically just stalled, and whom ever got around to working
> > on it decided that the old structs and vtables were fine. Why discuss at
> > all if they were?
> >
> > http://wiki.allegro.cc/index.php?title=ProposedVTables
> >
> >
> >From what I remember, we said in one of the IRC meetings that option F
>
> has won. Just nobody bothered to update that page. This means addons
> which provide an additional "driver" for something do have to access
> internals in A5, and just like AllegroGL had to be updated whenever we
> changed the A4 gfx driver vtable, such addons will have to be updated
> with A5.
>
> But, from what I understand, that's not the issue here at all. The above
> was for internal vtables only. The fshook API is supposed to provide a
> public "vtable" which the user fills in. It's the same as the function
> to set the alternate memory allocators (or the PACKFILE stuff in A4).
> The contents of the vtable *are* a public API here, if this public
> vtable changes it's the same as if any other public field of a structure
> changes, or if the prototype of a function changes. So no problem simply
> moving it from an internal to a public header.
With the original design, the vtables were not public at all. Just an enum and
a couple functions were. Id like to go back to that, it seems cleaner. But as
I said before, it looks strange against allegro's other bare vtables.
I for one don't see how the fshook vtables are any different from the graphics
drivers or anything else.
> --
> Elias Pschernig <elias@xxxxxxxxxx>
>
>
> ---------------------------------------------------------------------------
>--- 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