Re: Consensus on getter conventions?

[Maciej Stachowiak <mjs eazel com>]

"Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:

> Maciej Stachowiak <mjs@eazel.com> wrote,
> 
> > Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> > 
> > > Thus don't look to C++ kits for answers.   If fact isn't the concept
> > > of returning something which needs to be freed going to be a C concept
> > > only.  If you change the name of the function to show this convention
> > > then the bindings are going to end up with rather pointless name
> > > distinctions.  Why make that distinction for the bindings?  (and
> > > using multiple names is going to cause the distinction to be
> > > made in the bindings.)
> > 
> > The bindings could be made aware that this is a naming convention for
> > the C world and ignore it.
> 
> I don't really understand what you mean by `ignore' the
> convention.  The bound functions will end up having
> different names while there is no visible semantic
> difference between functions with different names.  So, it
> would seem in these languages as if the naming were not
> consistent. 

What I mean is: langauges where it makes no difference (i.e. just
about everything except C) could rename all the *_peek_* functions to
*_get_*; autogenerated bindings could have this convention encoded in
the code that generates them. 

This is actually sensible, because other languages will almost
certainly return something other than a reference to the C string in
any case.
 
> This makes it clearer, but renaming functions is not
> attractive for a binding, because it means that it becomes
> more difficult to use the standard documentation for the
> binding.

I agree this is a problem, but some documentation of the peek vs. get
convention could partially mitigate it.

 - Maciej