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

["Jonathon Jongsma" <jonathon jongsma gmail com>]

On 8/16/06, Murray Cumming <murrayc murrayc com> wrote:
> [snip]
> > 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.

Yes, that was my argument when I originally brought it up, but I admit
that the argument against using new_* in C++ is fairly convincing.
It's not that different than if a C function was called alloc_path
(OK, it is a little bit different since alloc can't really be
understood in several different ways like new can :).  That said, I'm
not totally opposed to retaining the new_* method names as long as the
documentation is very explicit about what they do.

> OK. That's worth thinking about then. Maybe we need to change _both_ methods.

And that's where this conversation ended last time, because nobody
came up with another naming scheme that retained the semantics of the
existing new_path / new_sub_path and also maintained the naming
parallellism.

> > 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.
>
> When this is necessary, let's make sure that we mention the C names in the
> documentation for those methods.

I will certainly do that if and when we come up with reasonable names
for the API.

--
jonner