Re (tilly) 2: Frivolous function names

I think that expectations are strongly shaped by what we have around us.

I have dealt with a lot of code with get methods that issue no complaint if you try to get what isn't there. None of it will autocreate just to succeed. So for me a get method that creates is very surprising.

As for which is stronger, well the fantasy connection is one reason I think in terms of summoning being stronger. The next image that comes to mind is comparing getting a person, when that person can just say, "Sorry, I'm busy" versus issuing a legal summons where if you don't show up, you can go to jail.

But still, if your expectations are opposite, the name is unclear. I should therefore change it... *sigh*

As for your class, I would have named it something like WaitingFor (or with the captitalization I use, waiting_for). But then again naming things is my least favorite part of programming...

Comment on Re (tilly) 2: Frivolous function names

Replies are listed 'Best First'.
(tye)Re2: Frivolous function names by tye (Sage) on Dec 09, 2001 at 02:46 UTC
Unfortunately WaitingFor is not a noun and so violates our coding standard for class names (which would probably lead to confusion even if we told the coding standards to take a flying leap in this case). We came up with other similar names that seemed clear but weren't nouns as well. For some reason, phrases were bouncing around in my head today: "We always summon our man!" Captain: "What are we going to do about this criminal?" Officer 1: "I'm going to summon him!" Officer 2: "I'm going to get him!" "I summoned the daemon." "Did you get him?" "No, it didn't work" Although "summon" denotes exercising authority, it also denotes letting the person that you seek decide whether or not to respond to that authority. It isn't an action, it is a request. Summon might even denote an asynchronous request to me where you issue the summons and then come back later to see whether anything responded. And I'm used to "get methods" being accessor methods for object attributes which are things you usually don't expect to fail. On the other hand, a "find" method implicitly means "try to find" for some reason. I guess because "to find" implies a non-trivial amount of work is involved and so it is unreasonable to rule out failure. Yeah, naming is one of the least rewarding parts of programming, while it can be surprisingly tricky, time-consuming, and important. - tye (but my friends call me "Tye")	[reply]

Replies are listed 'Best First'.

(tye)Re2: Frivolous function names
by tye (Sage) on Dec 09, 2001 at 02:46 UTC

Unfortunately WaitingFor is not a noun and so violates our coding standard for class names (which would probably lead to confusion even if we told the coding standards to take a flying leap in this case). We came up with other similar names that seemed clear but weren't nouns as well.

For some reason, phrases were bouncing around in my head today:

"We always summon our man!"
Captain: "What are we going to do about this criminal?"
Officer 1: "I'm going to summon him!"
Officer 2: "I'm going to get him!"

"I summoned the daemon."
"Did you get him?"
"No, it didn't work"

Although "summon" denotes exercising authority, it also denotes letting the person that you seek decide whether or not to respond to that authority. It isn't an action, it is a request. Summon might even denote an asynchronous request to me where you issue the summons and then come back later to see whether anything responded.

And I'm used to "get methods" being accessor methods for object attributes which are things you usually don't expect to fail.

On the other hand, a "find" method implicitly means "try to find" for some reason. I guess because "to find" implies a non-trivial amount of work is involved and so it is unreasonable to rule out failure.

Yeah, naming is one of the least rewarding parts of programming, while it can be surprisingly tricky, time-consuming, and important.

tye

[reply]