[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: outlet v. context
Re: outlet v. context
Tue, 7 Jul 2020 20:16:01 -0600
On Tue, Jul 7, 2020 at 5:32 PM Dan Eble <email@example.com> wrote:
> On Jul 7, 2020, at 19:20, Carl Sorensen <firstname.lastname@example.org> wrote:
> > The only time I would like a member function of a class to have a verb
> name is when it causes a side effect.
> > When the job of a function is to return a result that can be used
> elsewhere, to me the goal is a result, and hence, it is a noun. flag()
> refers to an object -- a flag. get_flag focuses on the action, not the
> result. And most often, it's the result that I want -- which is a noun.
> I'll flag() your message and consider it later this evening.
> Should we also consider the Scheme language?
> git grep 'ly:get' scm
I thought about this more while driving home, and thought back to all of my
C++ experience (which I admit, it much less than yours!).
My practice has been to have setter functions be written as verbs, and
getter functions to be written as nouns. I think that makes the most
readable code. But I have not developed that usage within the bounds of
any standard of which I am aware. I've just done it that way.
So in our code base, we have Dots.dot_count (a getter) which has the value
of the number of dots in the Dots grob. But Dots.dot_count, by default, is
calculated by dots::calc-dot-count (a setter). I would not want to have
Dots.get_dot_count be the name of a property.
I am happy with calc-foo() or set-foo(), since the intent of those
functions is clarified by the prefix word.
I don't feel like get_foo() is, in general, clearer than just foo() *for
member functions*. As a specific example, consider the AccidentalPlacement
grob, which is implemented in accidental-placement.hh and
accidental-placement.cc. I believe the member function add_accidental() is
properly named, because it is a setter -- it's used to change the internal
data structures. And in fact, it has a void return value.
On the other hand, I don't believe the member function
get_relevant_accidentals is a superior name to relevant_accidentals,
because the return value is in fact a vector of accidentals.
So at this point, I believe I would prefer that void functions be named as
verbs, such that they describe the effect of the function on the items that
are being affected by the function. My personal preference is that
functions with a return value be named as nouns that reflect value that is
But, as I said before, I'm not doing the work, so I expect my opinion to
have a relatively small weight. I'm not offended if the decision is to go
with get_foo(). It doesn't affect the users at all; it only affects the
developers. So the most active developers ought to feel free to make the