Misleading documentation on Block::registerCallable

[ashley-b]

I notice when I call Block::registerCallable on a method that has no arguments it does not register a slot for it.
I also noticed when I delved into the implementation that names that are prefix with underscore are treated as private and are not registered also. This should probable be mention in the docs

The doxygen for this method

/*!
* Export a function call on this block to set/get parameters.
* This call will automatically register a slot of the same name.
* \param name the name of the callable
* \param call the bound callable method
*/
void registerCallable(const std::string &name, const Callable &call);

[guruofquality]

I notice when I call Block::registerCallable on a method that has no arguments it does not register a slot for it.

Good catch, I noticed this too when I added clearChannels() to the plotters. And it was funny because I kind of expected argument-less calls to automatically become slots, its seemed intuitive.

But I didn't do that.... probably because I didnt want to register getters that return values. But calls that return void and have no arguments are not gettings, so that should probably the the determination, and not the number of args.

For reference

//automatic registration of slots for calls that take arguments and are not "private"
    const bool isPrivate = name.front() == '_';
    if (call.getNumArgs() > 0 and not isPrivate and _namedInputs.count(name) == 0) this->registerSlot(name);

[guruofquality]

Update: on master branch the codebase now uses the return type being void to register automatic slots. To facilitate the change -- its not an error throwing condition to call "registerSlot" for a call that was automatically registered.

No changes to the the private underscore rule. I found one place that used it, and it was the python block. I think this rule is probably unnecessary, although we may want a way to register a void return call and not make it a slot in the C++ API. So leaving this open for the time being.

[ashley-b]

Great, looks good. I just recompiled my block against the master and it seams all good. The void return slot gets registered with out registerSlot now and has no errors if I leave registerSlot in.
Thanks