[Ns-developers] NS-3 PyBindGen again

[Gustavo Carneiro]

On 07/01/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
>
> On Mon, 2008-01-07 at 12:42 +0000, Gustavo Carneiro wrote:
> > On 07/01/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> >         On Mon, 2008-01-07 at 11:29 +0000, Gustavo Carneiro wrote:
> >
> >         [snip]
> >
> >         > I won't comment on you specific implementation, but I have
> >         to question
> >         > whether this is really useful or not.  How often do you
> >         connect
> >         > callbacks from Python to C++ functions?
> >
> >         Quite often if you want to connect a C++ statistics class to a
> >         trace
> >         hook.
> >
> > Well, let's worry about that case when we have that C++ statistics
> > class,  shall we? :-)
> >
> > I don't have time to tackle all the problems at once...
> >
> >
> >         [snip]
> >
> >         >         Do you have an idea on how this could be
> >         implemented ? If so,
> >         >         could you
> >         >         outline briefly how you think it could be done ?
> >         >
> >         > This is where we have to provide a MakeCallback API to
> >         Python, the
> >         > types mangled into the name. Example:
> >         >
> >         > In C++:
> >         >
> >         > static void
> >         > CourseChange (const TraceContext &context, Ptr<const
> >         MobilityModel>
> >         > position)
> >         > {
> >         > [...]
> >         > }
> >         >
> >         > [...]
> >         >       notifier->TraceConnect ("/course-change", MakeCallback
> >         > (&CourseChange));
> >         > [...]
> >         >
> >         > In Python would be:
> >         >
> >         >
> >         > def CourseChange (context, position):
> >         >     [...]
> >         >
> >         > [...]
> >         >       notifier.TraceConnect("/course-change",
> >         >
> >
> MakeCallback__lt__const_TraceContext_amp_Ptr__lt__const_MobilityModel__gt____gt__(CourseChange));
> >         >
> >         > Yes, it's very ugly.  But I don't see any way around it with
> >         the
> >         > current API.
> >         >
> >         > It would be nice, though, if the API could be enhanced to
> >         provide
> >         > introspection of the required tracing callbacks.  An API
> >         like this
> >         > would be enough:
> >         >
> >         > const std::type_info GetTraceCallbackType(const std::string
> >         path)
> >         > const;
> >         >
> >         > Should I open a bug report?
> >
> >         This API is, however, impossible to implement in C++ as far as
> >         I know :/
> >
> > What about this patch?  I don't know how to integrate this "upstream",
>
> What do you intend the type_info to be used for ?


I can look at the type name use it to index a table mapping callback type
names to python callback wrapper classes.

>  but this code compiles which appears to indicate it can be done.  I
>
> This is really weird because my c++ spec states clearly that it is not
> possible to copy std::type_info objects. i.e., their copy constructor
> and assignment operators are expected to be private.


I ran into that problem, but then I changed the return type to "const
std::type_info &".  Returning by reference does not require copying, so all
is well.  Same could be done with TraceDoc, but TraceDoc offers a list of
strings, with each parameter type, matching by a single type name string is
much easier.

> This API (template <typename T> bool GetElement (T &context) const) is
> > based on templated methods.  I need to generate all method template
> > instantiations, but then the method names have to be mangled with the
> > type names.  Again, adding dynamic introspection features to the C++
> > API would be most welcome for Python bindings, else user will have to
> > call methods with mangled names.
>
> Clearly, asking the user to use mangled names is not a practical
> solution.


Well, this is one more example among many where NS-3 is favouring C++
programming in detriment of language bindings.  I have known this for a very
long time, and accept it.  That's why it is perhaps prudent to not wait
until NS-3 API is finalized to start making language bindings, because
making these bindings will shed some light on what needs to be improved in
the API in order to better support them...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert