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. 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
Attachment:
pgpySPX5c6sBW.pgp
Description: PGP signature