Shorten some function names?

[Dan Bonachea]

The names for the current VIS functions are rather unwieldy - notably including the 32-character rput_fragmented_regular_then_rpc.

It would be nice if the function name wasn't an entire sentence.

Doesn't the magic of overloading allow this to be simply rput?

Even if not, can we come up with something more concise and less cumbersome?

Same question applies to a lesser degree to rput_then_rpc. Perhaps this could be simply rputr?

I'll also note that we have rpc_ff not rpc_fire_and_forget, so we're not even consistent in our naming convention.

[Former user]

C++ culture tends to prefer lengthy names since they produce the most readable code. We specifically broke rput's overload set down because it was getting too large. Making the VIS funcs as overloads would be especially tricky since they take their iterators as generic template type parameters which could match anything at overload resolution time. The same applies to any call that takes function objects since those are also generic template parameters.

I like that we have shorthand names for our bread and butter (rput,rget,rpc_ff) which the user will be typing in great quantity and longer names for the esoteric parts. VIS especially is exactly the sort of code people write once under their own abstractions and never call directly again.

Consistency is a fair critique, but I would just say our rule is: short names for the frequently called, long names elsewhere.

[Scott Baden]

If we take out the "then" from "then_rpc" then I think that will meet our needs. As Dan points out, we are already abbreviating fire and forget, so we should be good. These names are too long and a prolbem with long names is that you end up with very long lines of code....

[Former user]

I think the "then" is essential. Otherwise it reads like we are putting an rpc somewhere.

[Dan Bonachea]

I agree with your predicted usage frequency, but basing a naming convention on expected usage frequency seems a bit dubious.

In any case, I guess what bothers me the most is the labeling "fragmented", "fragmented regular", and "strided", where the second one in particular seems overly cumbersome. What if all the VIS puts were overloads with a name like rput_noncontig()? At a very high level they are all doing the same thing (a non-contiguous put), they just have different options for the meta data arguments used to describe the non-contiguous payload being moved. The argument signatures for the three variants seem rather different to me (strided takes a global_ptr, a T* and 3 arrays, indexed takes 4 iterators and 2 size_t by value, vector takes 4 iterators), but I'm not sufficiently familiar with the rules to know if there would be overload ambiguity.

[Dan Bonachea]

This was discussed in our meeting today and the conclusion seems to be that using overloads to provide one function name for all the VIS functions would probably give a bad user experience.

The current names are not ideal, but we don't have a better replacement at this time.

There's also a possibility the _then_rpc variants will eventually be globally removed, in favor of a generalized completion mechanism.