Re: Consensus on getter conventions?

[Maciej Stachowiak <mjs eazel com>]

Derek Simkowiak <dereks@kd-dev.com> writes:

> -> I'd like to propose that we go with the convention of naming functions
> -> that return references to internal data *_peek_* and naming functions
> -> that allocate new memory *_get_*.
> 
> 	This would result in far more *_peek_* functions in the library
> than *_get_* functions, would it not?

That depends on which library. In gtk+ itself, *_peek_* would probably
outweigh *_get_* currently.

> 	In the past, we've used *_get_* for most everything, right?
> (That's not rhetorical, I'm really asking)

We've used *_get_* for both allocating and non-allocating functions.

> 	It seems to me that we would break less existing code, and be more
> like existing conventions (most notably JavaBeans) if we used *_get_* to
> get references and something else for newly-allocated references (maybe
> *_copy_*, since we're getting a newly allocated copy of what's in object)

Have you read the previous discussion regarding why something like
*_copy_* or *_dup_* is not acceptable? Often you are returning a
computed value, not just a copy of something that exists already.

Java is completely different - it's garbage collected, so whenever you
return an object it's as if you have implicitly upped the refcount.

> 	Question: Does Qt have a convention for this?  What about Motif?
> MS-Windows/Mac?

My goal was not to completely reopen the discussion here. We were
pretty close to consensus, then the discussion sort of fizzled out.

Most folks agree that the previous plan was acceptable. Nearly
everyone agreed we want different names for the two kinds of returns.
I propose we move forward with that plan and not bicker over naming
further.

 - Maciej