[cairo] Re: On recovery from errors in cairo (was: cairo reset)

[Mike Emmel]

On 9/23/06, Kalle Vahlman <kalle.vahlman at gmail.com> wrote:
> 2006/9/23, Mike Emmel <mike.emmel at gmail.com>:
> > On 9/23/06, Kalle Vahlman <kalle.vahlman at gmail.com> wrote:
> > > 2006/9/22, Carl Worth <cworth at cworth.org>:
> > > > I do understand that drawing something that's "wrong" in an obvious
> > > > way might make it easier to debug than setting an error. But, we don't
> > > > have an error in this case, we instead have the line_to implicitly
> > > > convert to a move_to. The motivation for this is to allow for code
> > > > which can loop over an array of points to set up a polygonal path:
> > > >
> > > >         for (i = 0; i < num_points; i++)
> > > >             cairo_line_to (cr, points[i].x, points[i].y);
> > > >
> > > > rather than having to special-case the first point:
> > > >
> > > >         for (i = 0; i < num_points; i++)
> > > >             if (i == 0)
> > > >                 cairo_move_to (cr, points[i].x, points[i].y);
> > > >             else
> > > >                 cairo_line_to (cr, points[i].x, points[i].y);
> > > >
> > > > Of course, the special-casing approach still _works_ just fine. I just
> > > > thought it would be kinder to allow the simpler approach above by
> > > > defining reasonable behavior instead of an error state.
> > >
> > > I can imagine not requiring an explicilty defined starting point (in
> > > the application context) could be annoying if it is not consistent
> > > throughout the API. A quick look indicates that it is, at least among
> > > the cairo_*_to()-functions.
> > >
> > Thats not true line_to does a move to but other functions like
> > cairo_rel_curve_to error instead of say doing a move_to 0, 0
> > then drawing. Which would be consistent with the way line_to
> > works. Same with  cairo_rel_line_to.
>
> Oh, I really did mean only the non-relative versions of the functions,
> sorry for not being exact. For relative operations setting the error
> is IMO warranted.
>
> > I'm sorry but the line_to -> move_to thing is a hack and if you read
> > the code it does not show you whats really going on unless your
> > aware of the hack.
>
> It's clearly documented though. If you see code that does not
> explicitly set the starting point you'll look the definition for such
> case in documentation instead of just assuming it means "from 0,0",
> right?
>

I did not say it was not documented just that the code itself does two different
things depeding on the if a current point is set. So the behavior changes based
on a external and potentially unrelated event i.e setting the current point.
This could happen or not happend in a complex code base for a variety
of reasons. So the the code and the design is increadibly fragile. Its
a hack documented or not is irrelevent.

The underlying problem is allowing paths to exist in a undefined state
and allowing some operations to be performed before the current point
is set its a logical flaw.
Documenting it does not somehow make it correct. If you take my
proposal of always initializing a path to 00 on construction and look
at the internals of the code you will see its a far more elegant and
consistent and robust approach then
trying to support a subset of possbile operations on a undefined object.

Like I said in my big long winded post Cairo is not ready yet we can
either fix it now or at some point a fairly incompatible major release
will occur I've been programming long enough to feel very comfortable
to predicting this. I don't understand why there is so much pressure
to finalize cairo since its just barely reached the point that apps
can exercise most of the api in a real world setting.

I've said enough I think on the subject so I don't want to argue this anymore
either we do a review of the current state of cairo and make the
changes now that is good enough to actually use or we keep trying to
take the current version forward with a too early promise of
compatibility.



> --
> Kalle Vahlman, zuh at iki.fi
> Powered by http://movial.fi
> Interesting stuff at http://syslog.movial.fi
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>