[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Export services?

From: Chia-I Wu
Subject: Re: [ft-devel] Export services?
Date: Sat, 15 Oct 2005 06:43:46 +0800
User-agent: Mutt/1.5.11

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]