[cairo] cairomm new_path / clear_path

[Bill Spitzak]

Isn't new_sub_path() resulting in the same state as close_path() except 
the previous subpath is not closed? It's also the same as the initial 
state after new_path(). Might be better to word it after it's effect on 
the previous subpath, perhaps end_path() or end_sub_path() or something.

Murray Cumming wrote:
> On Wed, 2006-07-05 at 08:29 -0600, Rick L Vinyard Jr wrote:
>> Jonathon Jongsma wrote:
>>> There's a function cairo_new_path() which has been wrapped in cairomm
>>> as Context::clear_path().  As far as I can tell, this is just about
>>> the only function whose name was changed from cairo to cairomm.  With
>>> the addition of a new API cairo_new_sub_path (which I wrapped as
>>> Context::new_sub_path), there's no longer an obvious correlation
>>> between these functions in cairomm.  I would propose changing
>>> clear_path() back to new_path().  Is anybody opposed to this?
>>>
>>> cairomm has not been declared API stable yet, so I think we can get
>>> away with changing it now, but we should do it soon if we want to do
>>> it.
>> Personally, I think that clear_path() is better.
>>
>> I know it is a deviation from the C cairo library, but in C++ 'new' has 
>> a specific connotation (dynamic allocation) that is not present in C.
> 
> Yeah, it doesn't allocate an object so it shouldn't be called new*. That
> would just lead to confusion. clear_*() makes a little more sense in
> terms of the documentation.
> 
> start_new_path() is also a candidate (for the C function too, though
> it's too late for that), but I still don't like the new in the middle.
>