Bug 2086

Summary:	Commit 77c498aed31f breaks attribute accessibility
Product:	ns-3	Reporter:	Peter Barnes <pdbarnes>
Component:	core	Assignee:	Peter Barnes <pdbarnes>
Status:	PATCH WANTED ---
Severity:	normal	CC:	ns-bugs, tomh
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All

Description Peter Barnes 2015-04-01 13:13:44 UTC

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 UTC

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 UTC

+1 on reverting to PointerValue so that we can access attributes (perhaps by handling in doxygen introspection program as suggested)