[cairo] Re-working cairo_current_path

[Owen Taylor]

On Mon, 2005-01-24 at 11:01 -0800, Keith Packard wrote:
> Around 13 o'clock on Jan 24, Owen Taylor wrote:
> 
> > Would an opaque type with an iterator API work? E.g.:
> 
> I don't think this is complicated enough to require this, and I prefer the 
> transparency of a public datatype.  As long as the interfaces using this 
> datatype are well shielded from having to use the type internally, I think 
> it's fine to let people use regular C operators to manipulate the data.
> 
> The same goes for the cairo_matrix_t object; making this opaque isn't 
> protecting the API and only turns your C code into LISP.

I agree on exposing cairo_matrix_t ... though trying to keep track
of what matrix->surface[1][0] is is a continual struggle.

But in terms of the path, my argument really isn't about compatibility,
it's rather about complexity and cleanliness. 

The non-iterator approaches that have proposed so far involve either:

 - Some sort of "bytecode" with a mixture of doubles-as-enums and
   doubles-as-doubles.
 - Pointer arithmetic to walk to the next structure

Both of which are incredibly unpleasant. (Also, think language bindings.
An iterator approach might require some hand-glue, but translates 
directly into a nice API in a OO language.)

Though keeping cairo_path_t completely opaque could allow us to use
the same structure internally and externally... which simplifies
memory managemnet and has big advantages if you want people to be able
to save a path, do cairo_set_path() and have that be efficient.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050124/706a8502/attachment.pgp