|Perl: the Markov chain saw|
So which is which? To me, if I summon someone, then I'm not sure whether they will come in response to my summons or not. But if I "get" them, then, well, I must have got them. So my first reaction is that the "get" is more forceful than "summon" and so would be the one that would "do whatever it had to" to get me what I demanded.
Further, I would never use "summon" when requesting something that might not be available. I "summon" something specific that I assume already exists: "Summon Dr. Smith". While I might use "get" to request something that may or may not be handy: "Get a doctor".
But elsewhere in this thread it appears that you have chosen just the opposite arrangement, apparently considering "summon" as in "to summon a daemon".
So, no, I don't consider that a good choice of names.
I'm even a bit surprised that you use "get" for looking up things that might not be there. I'd expect a "get" routine to only fail as an exception and a "find" or "lookup" routine to note "none such to be found" as an unexceptional failure result.
But if the point is to note that creating an item first requires that you check if it already exists, then I'd certainly put something like "create", "make", or "new" in the function name. Though using underscore_laden_names certainly motivates one to keep the number of words in an identifier to an absolute minimum since get_or_create_foo() is a pain to type. But I consider that a reason to avoid using underscore_laden_names.
Just yesterday I was discussing how difficult it can be to come up with good names and how easily (and a bit surprisingly) a bad name can lead to bugs. We were trying to name the class the encapsulates what an operation is waiting for (it can be an event, a timeout, both, or "nothing" as in "I'm ready now" or "nothing" as in "I don't yet know what I want to wait for", etc.). Most of the names sucked because they used terms that had attracted specific computer science meanings like "event", "trigger", "condition", and "signal" or that could be read as more than one part of speech like "wake" (is "WakeEvent" an event that wakes something up or a request to wake up an event?).
I eventually proposed "WhenToWakeUp" half jokingly. But, although it isn't the type of thing you think of when asked to come up with a noun (which class names must be according to our coding standard), it actually is a noun phrase and seems to describe the purpose of the class very concisely and unambiguously (we actually implemented it as a nested class so its full name is ...WaitingOperation::WhenToWakeUp), though I'm probably missing some problematic interpretation. (:
So there is an example of a bit of a whimsical name.- tye (but my friends call me "Tye")