[Saga-devel] Adding a new (overloaded) method to an adaptor

[Hartmut Kaiser]

Paul,

> I've recently started working on the C++ implementation of the Service
> Discovery adaptor and have run into a slight problem.
> 
> There is currently one method implemented for service discovery which
> is list_services(std::string, std::string, std::string)
> I wish to add another, also called list_services that takes only two
> strings, i.e. list_services(std::string, std::string)
> 
> Having gone through all the code making the changes I'm left with a
> slight problem when building my adaptor,
>  there are errors due to "no matching function for call to
> `register_member_sync...."
> 
> Have I missed something or is there a bigger problem here?
> 
> In saga/impl/packages/sd/discoverer_cpi.hpp we have the following
> 
> ///////////////////////////////////////////////////////////////////////
> //////////////////////
> // register discoverer CPI functions
>     template <typename Derived>
>     inline bool
>     register_discoverer_functions(
>         std::vector<saga::impl::v1_0::cpi_info>& infos,
>         saga::impl::v1_0::cpi::maker_type maker,
>         saga::impl::v1_0::preference_type const& prefs,
>         saga::uuid const& cpi_uuid, saga::uuid const& adaptor_uuid,
>         std::string const& cpi_name)
>     {
>        bool retval = false;
>        saga::impl::v1_0::cpi_info info(saga::adaptors::discoverer_cpi,
>            cpi_name, maker, prefs, cpi_uuid, adaptor_uuid);
> 
>        typedef saga::impl::v1_0::discoverer_cpi base_cpi;
> 
>        SAGA_REGISTER_MEMBER(retval, info, base_cpi, Derived,
> list_services, prefs)
> 
>        infos.push_back(info);
>        return retval;  // is true if at least one function got
> registered
>      }
> 
> How do I go about registering my new, overloaded list_services method?
> 
> Am I barking up the wrong tree or do all methods need to be uniquely
> named?

It depends. If your new function should be exposed through the SAGA API then
you need to add it not only to the adaptor (obviously) but to the package as
well. In this case it's the easiest to make the function names unique.
Overloading function names is possible, but requires additional attention
while writing the adaptor registration functionality in the package.

If your new function is just something you need inside your adaptor you can
name it as you like, but you should avoid choosing a name similar to any
name used for the exposed functions (usually starting with sync_... or
async_...).

This limitation is due to the automagic behind adaptor function
registration. Choosing a name similar to the exposed CPI functions confuses
this detection magic. Which is what you're seeing.

HTH
Regards Hartmut