|
Bugzilla – Full Text Bug Listing |
| Summary: | pybindgen ns3.Object subclassing bug | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | core | Assignee: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mathieu.lacage |
| Priority: | P3 | ||
| Version: | pre-release | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | patch | ||
|
Description
Gustavo J. A. M. Carneiro
2008-06-19 10:06:50 UTC
I have a patch to fix this, but it would require making Object::Construct and Object::SetTypeId public. Created attachment 177 [details]
patch
Mathieu please comment on the proposal for making Object::Construct and
Object::SetTypeId public.
Why I need this can be seen from the patch:
+namespace ns3 {
+template <typename T>
+Ptr<T> CreateObjectPython (PyObject *pyobj, const AttributeList &attributes)
+{
+ Ptr<T> p = Ptr<T> (new T (), false);
+ p->set_pyobj (pyobj); /// <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+ p->SetTypeId (T::GetTypeId ());
+ p->Object::Construct (attributes);
+ return p;
+}
+
+} // namespace ns3
The function CreateObjectPython is the same as CreateObject, but adds a python specific call before Object::Construct. This is needed to register the python wrapper with the C++ instance before Object::Construct gets called, because Object::Construct calls a virtual method. Virtual method wrappers need access to the Python wrapper to check if the wrapper overrides the virtual method in Python, and if so, call the Python implementation.
(In reply to comment #3) > Mathieu please comment on the proposal for making Object::Construct and > Object::SetTypeId public. I hate the idea of making these methods public because they really expose low-level implementation details of that class. Can't you just add a friend method ? i.e., class Object { private: friend void PythonCompleteConstruct (Ptr<Object> object, const AttributeList &attributes); }; (In reply to comment #4) > (In reply to comment #3) > > Mathieu please comment on the proposal for making Object::Construct and > > Object::SetTypeId public. > > I hate the idea of making these methods public because they really expose > low-level implementation details of that class. private/protected is but one mechanism for marking APIs for internal use. Another popular way to accomplish the same goal, maybe you heard of it, is called "documentation". I hear people say great things about this "documentation" method... :-) The documentation technique would simply add a notice to the doxygen comment: """Note: this API is meant for integration with external object system implementations, such as language bindings, and should otherwise be considered internal.""" > Can't you just add a friend > method ? > > i.e., > class Object { > private: > friend void PythonCompleteConstruct (Ptr<Object> object, const AttributeList > &attributes); > }; > It's not nice to special case just for Python. What about the next object system that comes along? Personally I would prefer to make it public. (In reply to comment #5) > > Can't you just add a friend > > method ? > > > > i.e., > > class Object { > > private: > > friend void PythonCompleteConstruct (Ptr<Object> object, const AttributeList > > &attributes); > > }; > > > > It's not nice to special case just for Python. What about the next object > system that comes along? Personally I would prefer to make it public. If/when that happens, we could revisit that issue. OK, fixed with Mathieu's friend function suggestion. |