Bug 2086 - Commit 77c498aed31f breaks attribute accessibility
Commit 77c498aed31f breaks attribute accessibility
Status: PATCH WANTED
Product: ns-3
Classification: Unclassified
Component: core
ns-3-dev
All All
: P5 normal
Assigned To: Peter Barnes
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-01 13:13 EDT by Peter Barnes
Modified: 2015-04-03 17:42 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Barnes 2015-04-01 13:13:44 EDT
From Tom:

Peter, regarding this changeset: http://code.nsnam.org/ns-3-dev/rev/77c498aed31f

I'm realizing now that there is a tradeoff in doing this conversion. When such attributes are string values, the objects themselves are changeable.  However, when they are pointer values, the attributes and trace sources of the object become accessible.  It seems like we can't have both...

(I'm not saying to change this changeset, just that in general in the future we will need to choose between these)

- Tom
Comment 1 Peter Barnes 2015-04-01 13:18:18 EDT
IIRC, the patch was a big hammer to fix a minor documentation annoyance:  the default value for Ptr<X> printed in the API docs would be the actual address of the instance created by print-introspected-doxygen.cc.

Reading Tom's description, I would vote for supporting attributes and trace sources.  The other case (modifying the object) should be supported by moving object state to configurable attributes.

Two alternatives come to mind:

1.  Hack Ptr<> and/or print-introspected-doxygen to print a null pointer value instead.

2.  Hack something to try and print a string representation of the underlying object.
Comment 2 Tom Henderson 2015-04-03 17:42:59 EDT
+1 on reverting to PointerValue so that we can access attributes (perhaps by handling in doxygen introspection program as suggested)