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
Product: ns-3
Classification: Unclassified
Component: core
pre-release
All All
: P1 normal
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-20 13:54 UTC by Gustavo J. A. M. Carneiro
Modified: 2008-07-01 13:32 UTC (History)
0 users

See Also:


Attachments
patch (5.14 KB, patch)
2008-03-20 13:55 UTC, 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 Gustavo J. A. M. Carneiro 2008-03-20 13:54:23 UTC
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 Gustavo J. A. M. Carneiro 2008-03-20 13:55:10 UTC
Created attachment 117 [details]
patch
Comment 2 Mathieu Lacage 2008-03-26 10:33:53 UTC
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 Gustavo J. A. M. Carneiro 2008-06-09 13:54:37 UTC
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 :-/