[cairo] Re: cairomm API/ABI freeze?

[Carl Worth]

On Tue, 15 Aug 2006 21:29:41 -0500, "Jonathon Jongsma" wrote:
> On 8/15/06, Jonathon Jongsma <jonathon.jongsma at gmail.com> wrote:
> > On 8/15/06, Murray Cumming <murrayc at 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.

I am glad that other than this one function, cairomm has stuck closely
to the C naming. We've had the experience with Mono bindings, (at
least older versions), where users ask questions to us, and after
listening to the answers, go away saying things like "Hmmm... well,
I'll have to figure it out in Mono.cairo because it doesn't work like
that there." That kind of thing is frustrating, and I'm glad that we
definitely don't have any problem as severe as that in cairomm.

So, the "new_path" thing isn't as significant as that stuff, but while
I'm talking about it...

The rationale given for not using "new_path" in cairomm was to avoid
confusion with the notion of "new" in C++. I'm not a programmer that
spends enough time with C++ to know if the existence of a function
named "new_path" without performing a "new" operation would be more
confusing than the mismatch of cairomm with standard naming of cairo
functions.

I would have expected the appearance of the word "new" as a component
of a function name to be no more confusing than something like the
word "operator" appearing within a function name such as
cairo_set_operator, (where certainly no C++ programmer will confuse
this with C++ operator overloading). Or is it actually common in C++
libraries for "new" to be embedded as a component of a function name
and still retain the semantics of a standalone "new"?

It's totally your call as the maintainers of cairomm, but I guess I'd
just ask for one last consideration of whether "new_path" and
"new_sub_path" might not be usable without having to invent custom
names for these functions in cairomm.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060816/1d64c948/attachment.pgp