Re: [cairo] Re: cairomm API/ABI freeze?



On 8/16/06, Carl Worth <cworth cworth org> wrote:
On Tue, 15 Aug 2006 21:29:41 -0500, "Jonathon Jongsma" wrote:
> On 8/15/06, Jonathon Jongsma <jonathon jongsma gmail com> wrote:
> > On 8/15/06, Murray Cumming <murrayc murrayc com> wrote:
> > > So, with gtkmm 2.9/2.10 hard code freeze approaching, is there anything
> > > stopping cairomm from freezing API and ABI now?
> > > http://live.gnome.org/TwoPointFifteen
> > >
> > > Are there any remaining problems, bugs or open questions with
> > > cairomm?

I'm curious what the decision was for the naming of the binding for
cairo_new_sub_path?

The cairo mailing list discussion I saw on this question only talked
about rationale for deviating from cairo_new_path to
cairo_clear_path. But I never saw what was proposed or accepted for
cairo_new_sub_path.

The name of cairo_new_sub_path was definitely chosen to parallel the
name of cairo_new_path. But with the above deviation, you cannot have
the same parallelism since cairo_clear_sub_path would be a totally
incorrect name.

I didn't state my opinion in the earlier thread, but I definitely
don't like the idea of bindings changing the names of cairo functions.
It makes things harder on the users of the bindings since they cannot
take direct advantage of tutorials or advice that is not in their
custom dialect. (The users are forced to either memorize and apply the
name mapping transformation to the advice they read.) We've tried to
make this reasoning clear in the Bindings Guide appendix of the cairo
reference manual.

What about the following?
Cairo::Context::begin_new_path()
Cairo::Context::begin_new_sub_path()

Advantages:
- retains a pretty close mapping to the C cairo functions
- retains an obvious parallellism between the two functions
- prefix 'begin_' makes it clear that we're not using 'new' in the C++ sense

Disadvantages:
- ?

Thoughts? opinions? alternate suggestions?

(Murray, I know you're probably on vacation, but if you get this I'd
appreciate your opinion as well)

--
jonner



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