[Ns-developers] [ns3] wrapper classes in the Attributes API

[Mathieu Lacage]

hi raj,

before trying to answer your questions below, I will try to outline
briefly how we got where we are today.

1) Originally, we wanted to support a really nice-looking syntax which
would allow you to call Set on an object with pretty much any input
type. You could call Set (int), Set (MyClass), etc. The same would hold
true for the Get variants. int = Get (), etc.

2) All of the above was prototyped using a number of different
techniques:
  - template methods
  - conversion operators
  - overloading

3) It turns out that making 2) work well was beyond my abilities and, I
suspect that this is a problem inherent to the way C++ type resolution
work and interact with template argument deduction.

4) A relatively solid version of that API eventually made its way in
ns-3-dev and it used extensively conversion operators to make a
compromise between the nice syntax we wanted and the limits of what we
could achieve with c++. It turned out that this implementation was still
too complex for me to allow me to add support for a couple of remaining
features needed for the API documentation we wanted to generate in
doxygen. So, in the end, I proposed the current API and, since there was
no feedback beyond the ACK by tom, I merged it in.

5) What we have now is clearly somewhat more verbose than stricly needed
(at least, from a user point of view) but, it seems that this is the
only way I could make this whole crap work correctly without nasty
compiler messages at every corner. So, unless, someone comes up with a
better implementation, I doubt that it will change fundamentally.

6) The macros provided in src/core/attribute-helper.h were originally
written for tom because he wanted to make it very easy to give attribute
powers to user types: the feature they provide was originally written
using templates and they did go through all of the many versions of the
API so, the current macros are super nice and could be improved, mainly
by:
  - removing ATTRIBUTE_HELPER_HEADER_1
  - renaming ATTRIBUTE_HELPER_HEADER_2 to ATTRIBUTE_HELPER_HEADER
Both of which were on my todo at some point but which slipped under my
radar.

If you look at these macros, you will notice that a lot of them could be
_almost_ rewritten to use templates (and some are actually really
trivial templates already). If you try to do this, you will notice a
couple of interesting things:

  - template arguments cannot be of type std::string, or char * or const
char * which means that some of that code will be more painful to
implement than you think

  - the various rules of C++ linking with template intanciation will
make the challenge interesting

  - the result will be much more code to write for users who want to
give attribute powers to their classes which is not necessarily a bad
thing but, which, in this case, will be really painful because a single
typo in the user code will trigger very interesting compiler error
messages

All of which will contribute, I think, to something which is much more
error-prone to use (much more fragile) and much less understandable
because the template magic required to make that work is really scary.

What we have now is definitely low-tech but, from a practical
perspective, I think that it is a decent compromise between complexity
of implementation and features.


On Tue, 2008-05-20 at 23:39 -0400, Raj Bhattacharjea wrote:

> 1)  It seems to me that the object of the current wrapper API is to
> have some way to pass a bunch of different types into the Attributes
> system in a consistent way, using the same methods to do so for
> various types of Attributes.  The wrappers tell the Attributes system
> exactly which type of object is being passed in.

yes.

> 
> 2)  It also seems that the way in which attribute-helper.h defines
> macros is such that they automatically generate class definitions for
> wrappers in which a single find and replace on a typename suffices to
> differentiate the different classes.

yes.

> These two issues independently make me think of templates immediately,
> and it seems that using templates in both of these cases would work
> really well together.

If you try to look at the mercurial logs, you might be able to dig an
early version of the attribute system which used templates for that but
it was not anywhere near pretty :/

regards,
Mathieu