Bug 148 - Replace "std::string context" parameter with a more useful Config::Path parameter
: Replace "std::string context" parameter with a more useful Config::Path param...
Status: RESOLVED WONTFIX
: ns-3
simulation core
: pre-release
: All All
: P1 normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-03-20 13:54 EDT by
Modified: 2008-07-01 13:32 EDT (History)


Attachments
patch (5.14 KB, patch)
2008-03-20 13:55 EDT, Gustavo J. A. M. Carneiro
Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-03-20 13:54:23 EDT
My proposed Config::Path has more useful component retrieval and parsing
methods, for when you want to extract node index numbers etc. from the context.
 It also makes it very clear it is just a path; one less thing to learn.
------- Comment #1 From 2008-03-20 13:55:10 EDT -------
Created an attachment (id=117) [details]
patch
------- Comment #2 From 2008-03-26 10:33:53 EDT -------
I discussed this at length with gustavo on irc: while I do understand why he
wants to do this, I would personally go another route:

1) keep the current std::string context string in callback signatures
2) provide a Config::Path class which can be constructed from a string (cannot
be converted back to a string) and which performs the string parsing for you to
allow you to call simple methods such as GetElementAsString (1) or
GetElementAsUint32 (2)

Basically, I would take gustavo's proposed code but I would not use it as the
default context in callback signatures.

So, to summarize, I think that gustavo's code is useful. The only question is
how we want to integrate it and although I disagree with gustavo on how it
should be integrated, I don't think it is that important so, if anyone agrees
with gustavo, feel free to apply the patch as-is.
------- Comment #3 From 2008-06-09 13:54:37 EDT -------
This issue does not seem to have gotten traction.  If other developers are not
interested in the patch, it is better to discard it forever than break the API
later.  It needs to go in right now or not at all.  I am guessing not at all
:-/