On Fri, Oct 14, 2005 at 10:11:21PM +0200, David Turner wrote:
> the "wrapper" functions are here to protect the users of the service's
> implementation details. They have various advantages:
>
> - they expose a "clean" API that doesn't depend on internals of
> the font engine. Allowing us to redesign services when needed
>
> - services can be used either internally or to implement a public
> API.
> in other words, exposing services publicly has many problems:
>
> - it forces us to expose more internals of the font engine, which
> means less possibilities for improvements in the future. And
> it's not like we've not been burned by this already
> (i.e. FT_OPTIMIZE_MEMORY breaks rogue libraries)
> - it forces us to add a way to distinguish between "internal"
> and "public" services.
This won't be hard because we can list services like
{ SERVICE_ID, POINTER_TO_FUNCTION, PUBLIC_OR_NOT },
where PUBLIC_OR_NOT is the new field.
An exported service is like an exported function call, once get
exported, it allows no change. Or we may say it's a way for the modules
to export module-specific API. Since it is module-specific, I think
it's better exported by the module itself, and not by a wrapper function
in "base".
Currently, wrapper functions in "base" are either simply wrappers, which
are good candicates of services to be exported, or high-level functions
of the services, i.e. they ease the pain of using the low-level
services. In the latter case, we can hide the low-level service and
export a high-level one, like the wrapper function is. The bottom line
is, it's a way for the module to export API.
> And I don't see how they could make the engine "more powerful".
Those services I can think of are already wrapped :(
Hmm, maybe we can export the byte interpreter as a service, then a
client can use this service to show how intructions instruct a glyph
vividly.
--
Regards,
olv
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
