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

[Hartmut Kaiser]

Paul,

> >So, go ahead and use similar names if you like. I just strongly urge
> you not
> >to do so. There are more hidden things lurking around behind the
> scenes
> than
> >you might imagine. :-P
> 
> >As a sidenote: I'm planning to remove the currently existing,
> duplicate
> >function names on the adaptor level for all packages. We recently
> found
> a
> >gotcha in the template magic mentioned above which might be easiest to
> >overcome simply by disambiguating things by design.
> 
> So, this pretty much forces my hand I presume.  No function overloading
> by design in the adapters.  That causes us a problem or two but I
> suppose we can work around it.  It does mean however that when
> designing
> a new package/adapter two interfaces have to be designed, user to
> package and then package to adaptor, when really one might better.  Is
> this correct?

As long as nobody comes up with a better compile time scheme of detecting
the implemented adaptor functionality the answer is a weak yes. But I still
think it's not a big deal, as the adaptor interface isn't visible to the
user in the end. I don't expect to have to convey this subtlety to more than
a couple of people writing adaptors, so we're fine.

But again, feel free to use function overloading. The gotcha I mentioned
didn't show up in real use cases yet, I just know it's there. So far
everything worked well even in the context of function overloading.

> >> I know that this is fairly well hidden from the end user, it just
> feels
> >> wrong to effectively have a C++ interface to the adaptors and yet
> not
> >> be able to use function overloading.  It looks like it's not far
> from
> a
> >> plain C interface which would then make wrapping the adaptors with
> >> other languages a whole lot easier, unless I'm missing some
> subtlety.
> 
> >Come on. Now you're exaggerating.
> 
> Not really but that's a discussion for another day!

:-P

> I suppose what would be really useful now is some documentation on
> exactly how your macro-magic is working, what macros are available and
> what they do.  There's very little commenting in the source code so I
> presume it's all documented elsewhere and I've just been unable to find
> it.  Template/macro based meta-programming doesn't bother me in the
> slightest, I'm just having a bit of a hard time understanding some of
> the decisions/solutions.  With the amount of function name mapping
> going
> on there's probably also a huge list of function names that shouldn't
> be
> used and a complete list would be a lot more use than the list that I'm
> reverse engineering from the source.

Yep, I agree. Writing packages/adaptors isn't documented anywhere. I don't
like the macros either, but these save a lot of stupid typing. At some point
I tried to replace them with some template magic, but there are still things
you can't really implement using templates only, so we got stuck with what
we have.

BTW, there is an adaptor writers guide in the beginnings, but this is mostly
work in progress. At least we can claim to see light at the end of the
tunnel (even if its red shifted).

Even if the adaptor framework has a lot of functions implemented, I don't
think that to be a problem. Function overloading is discouraged from our end
for the functions exposing the adaptor functionality only. No other
restrictions apply.

Please feel free to ask if something isn't clear, I'll try to compensate for
the missing documentation.

Regards Hartmut