Re: some more issues with the new API

[Just van Rossum]

At 1:49 PM -0500 15-03-2000, Stefan Seefeld wrote:
>I'v a couple of other issues with FT2 which are mostly
>naming and type conventions. One is the following:
>
>FT_Library is defined as a FT_LibraryRec_ *, yet
>function take a pointer to a Library as argument,
>thus you end up with a double indirection. Why is
>FT_Library a pointer ?

That's only true for FT_Init_FreeType, in which case it is a return value.
All other functions take a plain FT_Library.

>To make another point clear from one of my last mails:
>
>with your glyph slot approach, you loose thread safety.
>You can't dereference the current glyph safely since it
>can at any time get invalidated through a parallel call
>to Load_Glyph in a different thread. I propose you decouple
>glyphs from their faces in that faces still act as a
>glyph factory, but they don't return a pointer to an
>internal static object, rather they return a heap allocated
>object which the caller of Load_Glyph is to delete once he
>is done.

After exchanging a couple of emails with Stefan, I finally understood his
point, and it is very good one indeed. Thread safety is one issue, a clean
OO API the another. To illustrate the latter point: the FT_GlyphSlot
face->glyph field is destroyed upon FT_Done_Face(), but this means I need
to hold on to the face object as long as I have a reference to the glyph
slot. With automatic object deallocation (as is needed for a Python
wrapper, and is highly desirable for a C++ wrapper) this is problematic. So
decoupling FT_GlyphSlot (which could then be renamed FT_Glyph) from
FT_Face, as Stefan suggests, seems a good move. These are some consequences
of this change (off the top of my head):

- the FT_Face->glyph field disappears.
- the FT_Glyph object no longer needs to be a linked list
- FT_Glyph objects need to always be explicitly destroyed in C
- FT_Get_Glyph_Bitmap() becomes a method of FT_Glyph: FT_Glyph_Get_Bitmap()
- the FT_Glyph object needs a reference to a memory handler

Basically this questions much of the FT2 architecture, so it would be a
major change. Still, I think it's important to go to the bottom of this,
since the better the C API is *now*, the longer it'll remain useful (ie.
the longer we can postpone FT3 ;-).

Just