A name of 'LookupMessageAndYield' is confusing. As a client of your MessageStore, I don't need to know that it 'looks up' the message before yielding it; I just want it yielded!
I would opt for 'Relinquish' or 'Surrender'. 'RelinquishMessage' or 'SurrenderMessage' are also possibilities, but being a "MessageStore" renders the extra "...Message" name's redundant. What do you think?

How about InitiateLookup() ?

Roy

How about:

CauseMessageToSurfaceSomewhereElse(int messageId)?

:)

TransferMessage, ForwardMessage, RedirectMessage ?

HandleMessage()?

DispatchMessage??
BeginDispatchMessage to signal asynch behaviour?
PumpMessage
ProcessMessage

/M

Clemens,

Haven't got a suggestion that isn't already mentioned. I think that LookupMessage() itself just delegates the handling to your messageStore, meaning that this method should probably be renamed as well.

public void YieldMessage(int messageId)
{
MessageStoreService messageStore = new MessageStoreService();
messageStore.YieldMessage(messageId);
}

Not to sure about using yield though, because of the usage in iterators (which still implies a return-ish kind of usage to me).

Frank

Clemens,
I think it's more of a 'Retrieve' or 'Identify' than a 'Yield'.
Dan

To bounce out to the real world for moment the first example that comes to mind is the post office but that isn't quite true. In mailing a letter your sending it to another recepient rather than sending it to yourself. That is more of the traditional queue model. Actually to beat a dead horse since everyone uses coffee house metaphors these days this is more like ordering your coffee in the morning. You place an order at the cash register and then pile up with everyone else at the other end of the counter waiting for them to give you your coffee. It usually happens in order, but not always depending on how busy there are and how good at workflow management the barista is. You place and order and pickup your coffee Given that I would propose:

OrderMessage and a counterpart PickUpMessage.

Also, given that your already working with a MessageStore having the word message in the method call strikes me as unnecessary. Anyway I like Order, PlaceOrder, PlaceRequest. Get away from the noun 'message' that insinuates you expect a physical return and instead emphasize the fact that what you are doing is requesting that an action take place.

Patrick

Considering the behavior, I would say that in a way you are "deferring" the message, and "withdrawing" from processing.

What about ExecuteLookupMessageCmd or SendLookupMessageCmd? Hard to tell whether that is appropriate without knowing more about the rest of the system...

In addition to all the other words already posted I would like to add ReleaseMessage since I think that is clearer than relinquish.

TransferMessage is also good especially if you draw the comparision to Server.Transfer.

InitMessageLookup could also be a good name since the process basically does initialize the message lookup.

It's not a tail call, a tail call is a way of writing recursive calls so they can be optimized into a loop. I think that the concept is a "continuation", though I'll confess I don't understand them very well. There were a bunch of posts in the last couple days on this:

http://lambda-the-ultimate.org/node/view/86
http://blog.colorstudy.com/ianb/weblog/2004/07/12.html#P130
http://patricklogan.blogspot.com/2004/07/understanding-continuations.html

Though if you're just looking for a word to describe the flow control, "call-with-current-continuation" probably isn't that helpful to the reader either.

How about BoardMessage ? Like a traveler on a plane, the execution path will "ride" the message.
On second thought, it's not intuitively clear enough to just "get it" directly from that name.

It looks like an asynchronous call, so I'd propose 'BeginLookupMessage'

It's asynchronous, so let's start with 'AsynchLookupMessage'. If we need more, perhaps we could add 'InitiateAsynchLookupMessage'.

Synonyms for initiate: admit, begin, commence, cook up, dream up, enter, fire up, get off, inaugurate, induct, install, instate, institute, intro, introduce, invest, kick off, launch, make up, open, originate, pioneer, rev up, ring in, set up, take in, take up, trigger, usher in

I suppose 'FireLookupMessage' might work.

Re-reading my prevous post, how about 'LaunchLookupMessage'? Then, we can claim it's 'RocketScience'!

I would think messageStore.YieldTo(messageId) seems right.

I like "Insert" and "Inject", because you are taking a message and inserting/injecting it into the system.

What about PlaceRequestXXX ?

I like Patrick's comment "Anyway I like Order, PlaceOrder, PlaceRequest. Get away from the noun 'message' that insinuates you expect a physical return and instead emphasize the fact that what you are doing is requesting that an action take place"

The action is 'SendCustomerLookupRequest' - the method is a request to the local function call to send a message and not to actually perform the customer lookup. It's more clearly stated in this form:

public void LookupCustomer(int customerId)
{
CustomerService cs = new CustomerService();
cs.PostRequest("FindCustomer",customerId);

}

In windows kernel-mode programming such a kind of deferred calls is bread-and-butter, so you could consider using the same terminology and naming conventions.

The term is Deferred Procedure Call, and in the DDK it is almost always referred to as DPC.

That's the terminology part. Let's go to naming now.

Kernel Mode Support APIs are organized in logical groups: Executive Support routines, Kernel Support routines, Memory Manager routines, Object Manager routines, IO Manager routines, etc. Each routine group has a distinct two-letter prefix.
So there is ExAllocatePoolWithTag, ExFreePool, KeSetTimer, KeCancelTimer, MmMapIoSpace, MmUnmapIoSpace, ObReferenceObject, ObReferenceObjectByPointer, IoCancelIrp, IoFreeIrp.

All the DPC-related routines have the Dpc suffix: KeInitializeDpc, KeInsertQueueDpc, KeRemoveQueueDpc. Similarly all IRP-related routines (Io Request Packet) have the Irp suffix.

So the naming convention you are looking for could be to prefix or suffix all yielding routines with 'Dpc'.

Check out both proposals to see how each feels:

public void LookupCustomerDpc(int customerId)
{
CustomerService cs = new CustomerService();
cs.FindCustomerDpc(customerId);
}

public void DpcLookupCustomer(int customerId)
{
CustomerService cs = new CustomerService();
cs.DpcFindCustomer(customerId);
}

The first criterion I can think of for choosing between the two has to do with how you enjoy member function names sorted in class view. In classes that have lots of Dpc routines, it might be better to use the prefix so all Dpc routines sort together. If you don't have many Dpc routines, and may want to have Dpc and non-Dpc flavours of the *same* operation, then the suffix will do better.

However there is a second criterion that may be more important to some people.
Personally I prefer naming things the way my mind operates, so as to make the source code read left-to-right as close as possible to natural language. This makes code a little easier to comprehend, especially after having spent a couple of hours in front of your monitors.

So the following line of code:

cs.FindCustomerDpc(customerId);

reads as follows in my head:

"My dear object 'cs' please find me a customer I am looking for using a deferred procedure call, and the following parameters ..."

while the following:

cs.DpcFindCustomer(customerId);

reads as

"My dear object 'cs' please use a deferred procedure call to find me a customer I am looking for, using the following parameters ..."

If you zoom out what you have is:

Suffix: Dear Object please do ... using ...
Prefix: Dear Object please use ... to do ..., using ...

The suffix feels like better English to me.

Cheers,
DST

You've got a lot of suggestions here and rather than adding perhaps another one like "Self Addressed Stamped Envelope" or whatever, I'm wondering if the effort to find the right name is proportional to the effort to find what happened to the request (for the one who has to maintain that).

Cheers,

Wolfgang