What do you think of this style for getter-putters?

[DSF]

Hello, group.

I though of this style for getters and putters, but I assume there
must be something about it that's inelegant, bad, or dare I use the
word of overkill...Evil! (Because I haven't seen it in any source.)

class foo
{
public:

void LeftPosition(int lpos) {leftposition = lpos;}
int LeftPosition(void) {return leftposition;}

void RightPosition(int rpos) {rightposition = rpos;}
int RightPosition(void) {return rightposition;}

private:

int leftposition;
int rightposition;
};

If I were to guess, I would say that people have an aversion to
identical names, save for case.

What do you think?

DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus

[Ian Collins]

DSF wrote:
> Hello, group.
>
> I though of this style for getters and putters, but I assume there
> must be something about it that's inelegant, bad, or dare I use the
> word of overkill...Evil! (Because I haven't seen it in any source.)
>
> class foo
> {
> public:
>
> void LeftPosition(int lpos) {leftposition = lpos;}
> int LeftPosition(void) {return leftposition;}
>
> void RightPosition(int rpos) {rightposition = rpos;}
> int RightPosition(void) {return rightposition;}

Inverted capitalisation aside, it's fairly common in code I've seen.

--
Ian Collins

[Mr Flibble]

Hi.

1) In C++ (void) is superfluous, () will suffice.
2) The getter functions should by cv-qualified as 'const'.
3) Personal taste but I prefer different name for setter function namely
'SetLeftPosition'.

/Flibble

[Jorgen Grahn]

Yes, and I have used the style now and then (although I try to avoid
thinking in terms of getters and setters).

The consts are missing, though -- the get functions should be const.
(Apart from other benefits from const, it's also a strong hint what
they do.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Paavo Helde]

DSF <nota...@address.here> wrote in
news:cv38ca5r9h4e47jgj...@4ax.com:

> Hello, group.
>
> I though of this style for getters and putters, but I assume there
> must be something about it that's inelegant, bad, or dare I use the
> word of overkill...Evil! (Because I haven't seen it in any source.)

[...]
> int LeftPosition(void) {return leftposition;}

Yes, get rid of void and add const. Then it's ok.

Cheers
Paavo

[Pavel]

When faced with such supposedly "personal taste" choice, I usually try
to approach it from the first principles and approach it as a project,
from requirements to implementation. Here is how I think about this
naming problem:

First principle:
- Source code's primary and by far most important reason to exist is to
be read by humans

Requirements:
Thus, the main requirement to the source code is to be (human-)readable.
In particular a function name role in it is to:
- identify a token to a reader as a function name in any context it can
be met
- give a reader a good idea of what the function does
- do the above for a reader as quickly and easy as possible

Analysis:
- to identify itself as a function *in any context*, a function name
should start with a verb
- to allow the reader distinguish easily between the two different
actions (in your case, getting and setting -- or putting as you call
it), the two functions should use different verbs
- to do the above for a reader as quickly and easy as possible the
naming should use a predominant idiom if exists.

In your case, there is a predominant idiom for selecting the verbs,
namely get and set, hugely popularized by Java Beans API.

An idiom more familiar to C++ users of using attribute name "in pure"
for both accessor and modifier does not satisfy the first and second
requirements. In addition, it is not a pure idiom as the C/C++-style
idiomatic "setters" sometimes return old value and, in other cases,
return reference to an object for chaining. Even though your examples
does none of it, the code reader will no way of knowing it looking while
reading the call site.

For the reasons above, I use get/set idiom and avoid C/C++ idiom above.
In terms of your original question, I guess I would agree it is "evil".

Hope this helps,
-Pavel

[asetof...@gmail.com]

Stefan wrote:"
<<
Procedure names should reflect what they do;
function names should reflect what they return.«
. "
This is not right: The function name
Should be what that function
does in few words ... Eg printf scanf strcpy fopen() [and not
FILEpointer()] etc
At last I see this in the C library
Qsort [not qsorted. ..] etc

[Pavel]

r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> Pavel <pauldont...@removeyourself.dontspam.yahoo> writes:
>> In your case, there is a predominant idiom for selecting the verbs,
>> namely get and set, hugely popularized by Java Beans API.
>

> We are not part of the Java culture, but of the C culture.
I am a part of software engineering culture. I do not think I will ever
identify myself as "XYZ language programmer". Selecting the
right-for-task level of abstraction is one of the key skills software
engineer should possess. Class member name is an abstraction pertinent
to multiple programming languages and is best selected at its own merit.
>
> Our guide, therefore, is Rob Pike, not the Java Language
> specification.
As per the above, I am don't have any sympathy to blind adherence to any
programming language-level Bible, be it JLS, K&R, Most Effective
Anything or any other thing of the kind. I do appreciate all of the
above for good ideas and mean to ignore bad ideas when I see them. I try
to distinguish between good and bad ideas based on rationally defined
criteria.
>
> The JLS says:
>
> »Method names should be verbs or verb phrases«.
>
> But we can see that, using method names such as »main«,
> »max«, or »sin«, they do not follow their own recommendation!
>
> Rob Pike has understood better what governs common

> semantics. He wrote:
>
> »Procedure names should reflect what they do;
> function names should reflect what they return.«

So, how is the name for setter like "precision" you are suggesting below
reflects what the setter "returns"? You do not seem to follow your own
rules.
>
> http://www.lysator.liu.se/c/pikestyle.html
>
> Do you want to write:
>
> y = arctan( x/ sin( t ))
>
> or would you prefer:
>
> y = calculateArctan( x/ calculateSin( t ))
>
> or
>
> y = getArctan( x/ getSin( t ))
>
> ?
calcArctan or calc_arctan would not be bad. Unfortunately, there is no
supporting idiom: the predominant idiom for naming math functions is to
follow math notation. Math notation was developed for conciseness rather
than readability; and there were multiple reasons for that, both
rational (to shorten manuscripts that were expensive to produce) and
irrational (to hide knowledge from uninitiated).
>
> Thus, setters can be written with »set« as they are
> procedures, but getters should just be named after
> the value they return as programmers have always done.
I am all for following traditions till they don't harm the goal and I do
not see following traditions as a worthy goal in itself. As I mentioned
earlier, my main requirement to the code is readability. Not indicating
in a getter name that it is a getter harms readability in some important
contexts. For example, when the code uses getter name in argument to a
function or initializer, how will a reader know whether the code refers
to data or function member?
>
> A C++ programmer always can follow the style of the
> standard library,
They can but they do not have to and it is not always a good idea. C++
library design is full of both good and bad ideas.
and there we have:
>
> getter: cout.precision();
> setter: cout.precision( 12 );
>

[Jorgen Grahn]

On Sun, 2015-01-25, Pavel wrote:
> DSF wrote:

...

> When faced with such supposedly "personal taste" choice, I usually try
> to approach it from the first principles and approach it as a project,
> from requirements to implementation. Here is how I think about this
> naming problem:
>
> First principle:
> - Source code's primary and by far most important reason to exist is to
> be read by humans

I agree.

> Requirements:
> Thus, the main requirement to the source code is to be (human-)readable.
> In particular a function name role in it is to:
> - identify a token to a reader as a function name in any context it can
> be met
> - give a reader a good idea of what the function does
> - do the above for a reader as quickly and easy as possible
>
> Analysis:
> - to identify itself as a function *in any context*, a function name
> should start with a verb
> - to allow the reader distinguish easily between the two different
> actions (in your case, getting and setting -- or putting as you call
> it), the two functions should use different verbs
> - to do the above for a reader as quickly and easy as possible the
> naming should use a predominant idiom if exists.
>
> In your case, there is a predominant idiom for selecting the verbs,
> namely get and set, hugely popularized by Java Beans API.
>
> An idiom more familiar to C++ users of using attribute name "in pure"
> for both accessor and modifier does not satisfy the first and second
> requirements.

Calling them "requirements" make them sound more important that they
are. They are criteria you invented.

> In particular a function name role in it is to:
> - identify a token to a reader as a function name in any context it can
> be met
> - give a reader a good idea of what the function does

One problem I have with that is that I don't care about function
names: what I care about the full prototype of the function.
- Is it a member of some class? Which one?
- Is it const?
- Is it in some namespace?
- What are its arguments?
- What is its return type?

Just the name isn't enough.

I realize (I hope most people do) that the readability matters more at
the many places where the function is /called/, compared to where it's
defined. Not all of the information I listed is available at the call
site, but it's usually enough so you won't have to duplicate
knowledge from the prototype into the pure function name.

In DSF's case, for example, it's ok, since you cannot easily confuse
the setter and the getter:

struct Bar {
Foo foo() const; // "a Bar object's Foo value"
void foo(Foo); // "change the Foo property of a Bar object"
};

/Jorgen

PS. I also (to my surprise) agree with everything in Stefan Ram's
reply -- it probably explains why I think this way. Thank you,
Mr Pike!

[Bo Persson]

I think you should consider what it means to set the left position.
Depending on what a foo is, a better function name might be 'move' or
'resize'.


Bo Persson

[asetof...@gmail.com]

Pavel wrote:"
rationally defined
criteria."

Rational is not enough...
try for see if it is ok... 👌 is
enough

[DSF]

On Sun, 25 Jan 2015 10:39:43 +1300, Ian Collins <ian-...@hotmail.com>
wrote:

Inverted capitalization? I've always used mixed case for functions
and all lower case for variables.

[Greg Martin]

On 2015-01-25, Pavel <pauldont...@removeyourself.dontspam.yahoo> wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> Pavel <pauldont...@removeyourself.dontspam.yahoo> writes:
>>> In your case, there is a predominant idiom for selecting the verbs,
>>> namely get and set, hugely popularized by Java Beans API.
>>
>> We are not part of the Java culture, but of the C culture.
> I am a part of software engineering culture. I do not think I will ever
> identify myself as "XYZ language programmer". Selecting the
> right-for-task level of abstraction is one of the key skills software
> engineer should possess. Class member name is an abstraction pertinent
> to multiple programming languages and is best selected at its own merit.

I felt sympathetic to Stephan Ram's point, whether for the same reasons
or not I can't say. What I have seen come out of Java, and the elevation
of GOF and others, is this strange adherence to priciples that are
questionable. It's worth noting that much of that work came out of
Smalltalk, a language that by and large collapsed under its own weight
- a fate that might resonate with the Java language where there seems to
be a great excess of architects running around concerning themselves more
with patterns, case and naming conventions then correctness and efficiency.

>>
>> Do you want to write:
>>
>> y = arctan( x/ sin( t ))
>>
>> or would you prefer:
>>
>> y = calculateArctan( x/ calculateSin( t ))
>>
>> or
>>
>> y = getArctan( x/ getSin( t ))
>>
>> ?
> calcArctan or calc_arctan would not be bad. Unfortunately, there is no
> supporting idiom: the predominant idiom for naming math functions is to
> follow math notation. Math notation was developed for conciseness rather
> than readability; and there were multiple reasons for that, both
> rational (to shorten manuscripts that were expensive to produce) and
> irrational (to hide knowledge from uninitiated).

Herein lies the rub; to suggest that arctan in some way is not adequate
is to suggest those supporting the software using the functions are
inadequate for the task.

--
http://www.softsprocket.com

[Ian Collins]

Most coding styles I've used capitalise type names.

--
Ian Collins

[DSF]

On Sat, 24 Jan 2015 16:36:05 -0500, DSF <nota...@address.here>
wrote:

>Hello, group.
>
> I though of this style for getters and putters, but I assume there
>must be something about it that's inelegant, bad, or dare I use the
>word of overkill...Evil! (Because I haven't seen it in any source.)
>
>class foo
>{
>public:
>
>void LeftPosition(int lpos) {leftposition = lpos;}
>int LeftPosition(void) {return leftposition;}
>
>void RightPosition(int rpos) {rightposition = rpos;}
>int RightPosition(void) {return rightposition;}
>
>private:
>
> int leftposition;
> int rightposition;
>};
>

> What do you think?

To address two concerns:

Const. I assume you mean:
int RightPosition(void) const {return rightposition;}
since there's no need to mark a return by value as const. These
were just quick examples I typed into the newsreader. In actual code,
it's const.

Void. It is not necessary, but on the other hand causes no
problems. Since I'm often dealing with C and C++ code simultaneously
(I sometimes need to tweak my libraries written in C and assembly), It
adds a clarity for me. Kind of like tagging a derived member of a
base class member that's virtual as virtual...it's not necessary, but
it adds clarity.

[Mr Flibble]

On 25/01/2015 19:44, DSF wrote:
>
> Void. It is not necessary, but on the other hand causes no
> problems. Since I'm often dealing with C and C++ code simultaneously
> (I sometimes need to tweak my libraries written in C and assembly), It
> adds a clarity for me. Kind of like tagging a derived member of a
> base class member that's virtual as virtual...it's not necessary, but
> it adds clarity.

In this case less is more IMO; I imagine the superfluous (void) will
take your brain longer to grok than a simple ().

/Flibble

[Pavel]

Just an idea I picked up recently: I used to start all function names
with lower-case letter but I saw another style that differed in that the
first letter of *free-standing and static* functions names was
capitalized and changed to that. I liked it because, as you are reading
some non-static member function code and meet some call to another
function, it is good to have a clue whether it is another non-static
member function of same class (i.e. it implicitly gets the pointer to
the whole object) or it is a static member/standalone function that only
gets its arguments.

-Pavel

[Louis Krupp]

Your brain, perhaps. Mine likes the parentheses separated by
something, and I find (void) easier to parse than (). And having
evolved to the point where we have words and symbols for concepts like
zero and the empty set, () in a function declaration seems like a step
backwards. It also seems like a lexical if not semantic return to the
ambiguity of the original K&R C function declaration, and I am old
enough to remember having to transition from that to ANSI C.

Sometimes I miss ALGOL. If you wanted a procedure, you declared a
procedure. If it was a typed procedure, you declared a typed
procedure. If it didn't have an argument list, you didn't need
parentheses at all.

But I digress...

Louis

[Pavel]

Depends on the "task". I defined the task as "readability". BTW I am
fully ok with atan (this is the real name, btw, rather than arctan)
because it is the only known idiom so anyone who programmed in the
domain area will recognize it, regardless of the programming language.
BTW I think it is telling that Stephan did not get the function name
right even though he is advocating "C/C++" style. Isn't this a live
proof that readability matters, sometimes even more so than idioms?

-Pavel

[Greg Martin]

LOL. And I went along with it!

The problem with readability, in my POV, is that it depends on who is
reading. To someone versed in Lisp it is a very readable language but to
someone who isn't it simply seems wrong.

If I see a function I'm not familiar with I look up the
definition/documentation.

--
http://www.softsprocket.com

[Pavel]

You are certainly correct, all I am saying I take them as requirements.
It is fair to argue about whose requirements are better -- but it is
only possible after they are explicitly listed by both sides of an argument.

>
>> In particular a function name role in it is to:
>> - identify a token to a reader as a function name in any context it can
>> be met
>> - give a reader a good idea of what the function does
>
> One problem I have with that is that I don't care about function
> names: what I care about the full prototype of the function.
> - Is it a member of some class? Which one?

You might be interested to see my post in response to Ian Collins in
this thread about a convention that may give some clue.
> - Is it const?
getter-setter pattern gives you a good clue, I reckon. At least, you
have a fairly good idea that setXxx setter is not const, no?

> - Is it in some namespace?
> - What are its arguments?
> - What is its return type?

Don't you sometimes also want to know what the function does? :-)

> Just the name isn't enough.

I think it depends on the purpose of the reading. If you are looking for
a bug, you need all this stuff above. If you want to understand what the
code does (e.g. to add a feature or for any other reason) rather than
exactly how it maps whatever the author wanted to do to C++, telling
function name would certainly be more useful than a prototype of a
poorly named function (unless you get a good comment with the prototype
but this is probably outside of scope of this discussion). And if you
are doing bug-searching etc, such names would not hurt, at the very least.

>
> I realize (I hope most people do) that the readability matters more at
> the many places where the function is /called/, compared to where it's
> defined. Not all of the information I listed is available at the call
> site, but it's usually enough so you won't have to duplicate
> knowledge from the prototype into the pure function name.
>
> In DSF's case, for example, it's ok, since you cannot easily confuse
> the setter and the getter:
>
> struct Bar {
> Foo foo() const; // "a Bar object's Foo value";
> void foo(Foo); // "change the Foo property of a Bar object"
> };

You can easily confuse these if the name use is not calling the member
but passing its address as an argument to another function call or uses
it as a part of an initializer.

>
> /Jorgen
>
> PS. I also (to my surprise) agree with everything in Stefan Ram's
> reply -- it probably explains why I think this way. Thank you,
> Mr Pike!

Telling the truth, I did not find any rational arguments in Stefan Ram's
post against get/set convention. The principles he quoted from the book
are fully satisfied get/set convention. Indeed, getPrecision() reflect
"what the function returns" at least as well as precision(). And
certainly precision(6) (which should be a "procedure" in Mr. Pike's
terms) does *not* reflect *what the procedure does*; in fact, the whole
design of iosbase::precision(streamsize) API is bad because it does more
than one thing: it is a getter+setter rather than a pure setter, an
unfortunate inheritance from early times of C when API leanness trampled
readability (and, BTW, performance, too). So I would claim get/set
convention satisfies Mr Pike's rules (as cited by Stefan Ram because, I
have to admit I did not read the book) better than "pure attribute name
for both" convention., too.

-Pavel

[Chris M. Thomasson]

> "Geoff" wrote in message
> news:o03bcal6atpe7l3nr...@4ax.com...

> > On 25 Jan 2015 22:49:53 GMT, r...@zedat.fu-berlin.de (Stefan Ram)

> > Usually, I write the most readable and obvious:
> >
> >arcus = arcus_cuius_tangens_est( tangens );
> >
> > .

> angle = tan_to_the_minus_one(tangent);

;^)



Well, I have been known to be fairly verbose wrt naming
some functions:

http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_mingw_asm.html

;^o

[Louis Krupp]

On 25 Jan 2015 22:49:53 GMT, r...@zedat.fu-berlin.de (Stefan Ram)

> Usually, I write the most readable and obvious:
>
>arcus = arcus_cuius_tangens_est( tangens );
>
> .

Ego amo eam.

Louis

[DSF]

On Mon, 26 Jan 2015 08:34:49 +1300, Ian Collins <ian-...@hotmail.com>

How are you defining type names here? You obviously don't mean
typename, there's not a template in sight! :o)

[Ian Collins]

"foo"

--
Ian Collins

[DSF]

On Sun, 25 Jan 2015 20:40:40 +0000, Mr Flibble
<flibbleREM...@i42.co.uk> wrote:

Since my IDE has syntax highlighting and keywords are in bold type
and void is a keyword, int foo(**void**) jumps off the LCD at me.
Instantaneous grokking! (** to simulate bold type.)

[asetof...@gmail.com]

I wrote:"
This is not right: The function name
Should be what that function
does in few words ... Eg printf scanf strcpy fopen() [and not
FILEpointer()] etc
At last I see this in the C library
Qsort [not qsorted. ..] etc
"

If one function has need error return my
convention is:

i32 thisFunctionDoesThis(PointerToResult, arg1, ..., argn)

what it return is error in int 32 bit form...

[Tobias Müller]

My guess is that he actually meant functions in the mathematical sense
(pure, without side effects).

Tobi

[Jorgen Grahn]

Or in the Pascal sense: they have a return value. Pike doesn't
really define the terms (perhaps it wasn't necessary in the 1980s,
when Pascal was big?) but he says "Functions are used in expressions
[...]".

And then he goes on to give examples:

if(checksize(x)) // bad
if(validsize(x)) // good

and it strikes me that 25 years later, too many people haven't
even gotten /that/ right.

/Jorgen

[Jorgen Grahn]

On Sun, 2015-01-25, Greg Martin wrote:
> On 2015-01-25, Pavel <pauldont...@removeyourself.dontspam.yahoo> wrote:
>> r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>>> Pavel <pauldont...@removeyourself.dontspam.yahoo> writes:
>>>> In your case, there is a predominant idiom for selecting the verbs,
>>>> namely get and set, hugely popularized by Java Beans API.
>>>
>>> We are not part of the Java culture, but of the C culture.
>> I am a part of software engineering culture. I do not think I will ever
>> identify myself as "XYZ language programmer".

But you have to adapt to the people you're working with, and it's a
fact that cultures are different. (Not that there is a single C++
culture.)

>> Selecting the
>> right-for-task level of abstraction is one of the key skills software
>> engineer should possess. Class member name is an abstraction pertinent
>> to multiple programming languages and is best selected at its own merit.
>
> I felt sympathetic to Stephan Ram's point, whether for the same reasons
> or not I can't say. What I have seen come out of Java, and the elevation
> of GOF and others, is this strange adherence to priciples that are
> questionable. It's worth noting that much of that work came out of
> Smalltalk, a language that by and large collapsed under its own weight

...

I don't know the status of Smalltalk (I've never seen it). But I know
it's quite different from C and C++, and I think it shines through, in
that things like GOF design patterns sometimes seem a bit out of place.

[Jorgen Grahn]

On Sun, 2015-01-25, Pavel wrote:
> Jorgen Grahn wrote:
>> On Sun, 2015-01-25, Pavel wrote:

...

(Late reply -- sorry.)

>>> In particular a function name role in it is to:
>>> - identify a token to a reader as a function name in any context it can
>>> be met
>>> - give a reader a good idea of what the function does
>>
>> One problem I have with that is that I don't care about function
>> names: what I care about the full prototype of the function.
>> - Is it a member of some class? Which one?
> You might be interested to see my post in response to Ian Collins in
> this thread about a convention that may give some clue.
>> - Is it const?
> getter-setter pattern gives you a good clue, I reckon. At least, you
> have a fairly good idea that setXxx setter is not const, no?
>> - Is it in some namespace?
>> - What are its arguments?
>> - What is its return type?
> Don't you sometimes also want to know what the function does? :-)

Sure, that's what we're both talking about: how to give clues in the
code to help people remember what the function does, while keeping the
code as a whole readable.

>> Just the name isn't enough.
> I think it depends on the purpose of the reading. If you are looking for
> a bug, you need all this stuff above. If you want to understand what the
> code does (e.g. to add a feature or for any other reason) rather than
> exactly how it maps whatever the author wanted to do to C++, telling
> function name would certainly be more useful than a prototype of a
> poorly named function (unless you get a good comment with the prototype
> but this is probably outside of scope of this discussion). And if you
> are doing bug-searching etc, such names would not hurt, at the very least.

Here we disagree. I am not arguing for /badly named/ functions: I'm
arguing that the name is just a piece of the function's signature,
and needs to be seen in that context.

But yes, if you take one of my signatures and strip off everything but
the function name, you'll end up with a not very useful name!

>> I realize (I hope most people do) that the readability matters more at
>> the many places where the function is /called/, compared to where it's
>> defined. Not all of the information I listed is available at the call
>> site, but it's usually enough so you won't have to duplicate
>> knowledge from the prototype into the pure function name.
>>
>> In DSF's case, for example, it's ok, since you cannot easily confuse
>> the setter and the getter:
>>
>> struct Bar {
>> Foo foo() const; // "a Bar object's Foo value";
>> void foo(Foo); // "change the Foo property of a Bar object"
>> };
> You can easily confuse these if the name use is not calling the member
> but passing its address as an argument to another function call or uses
> it as a part of an initializer.

I don't think the risk is normally very high -- and I'm prepared to
make exceptions for special cases.

/Jorgen

[Pavel]

I am not certain I understand the challenge here. I thought, if a person
is likely to guess correctly what a function does, it plainly
contributes to the readability. I am all for the good prototypes for a
number of reasons but I do not see how they can significantly help to
understand what the function does. At a function call or other reference
site, the prototype or signature is not always obvious, especially in C++.

>
>>> Just the name isn't enough.
>> I think it depends on the purpose of the reading. If you are looking for
>> a bug, you need all this stuff above. If you want to understand what the
>> code does (e.g. to add a feature or for any other reason) rather than
>> exactly how it maps whatever the author wanted to do to C++, telling
>> function name would certainly be more useful than a prototype of a
>> poorly named function (unless you get a good comment with the prototype
>> but this is probably outside of scope of this discussion). And if you
>> are doing bug-searching etc, such names would not hurt, at the very least.
>
> Here we disagree. I am not arguing for /badly named/ functions: I'm
> arguing that the name is just a piece of the function's signature,
> and needs to be seen in that context.
>
> But yes, if you take one of my signatures and strip off everything but
> the function name, you'll end up with a not very useful name!

It's not me, it's the reference site that one will be reading and at
which there may be less than perfect information about the prototype.
Understanding reference site is important because it's the most often
context where the reader would meet a name of useful function.

>
>>> I realize (I hope most people do) that the readability matters more at
>>> the many places where the function is /called/, compared to where it's
>>> defined. Not all of the information I listed is available at the call
>>> site, but it's usually enough so you won't have to duplicate
>>> knowledge from the prototype into the pure function name.
>>>
>>> In DSF's case, for example, it's ok, since you cannot easily confuse
>>> the setter and the getter:
>>>
>>> struct Bar {
>>> Foo foo() const; // "a Bar object's Foo value";
>>> void foo(Foo); // "change the Foo property of a Bar object"
>>> };
>> You can easily confuse these if the name use is not calling the member
>> but passing its address as an argument to another function call or uses
>> it as a part of an initializer.
>
> I don't think the risk is normally very high -- and I'm prepared to
> make exceptions for special cases.

The problem is that when one selects a name for a new publicly
accessible function he or she has no control on how the function will be
used. If the function turns out to be really useful, it is only more
probable that people might eventually want to pass it as an argument
etc. or initialize some pointer with it. Specifically it is almost
common to store setters in a map with a textual key to fill up some data
structures read from external sources such as configuration files. By
the time such usage is needed, it might be too late for the name change.
> /Jorgen
>
-Pavel