[Ns-developers] Bug 215 Name Container

[craigdo@ee.washington.edu]

> Actually I was expecting NameList to be a simple wrapper 
> around std::map<
> std::string, Ptr<Object> >.  If that were so, it would so 
> much clearer that
> what you would do with NameList::Add would be
> 
> NameList::Add (std::string name, Ptr<Object> object)
> {
>    m_map[name] = object;
> }

Well, I suppose if you first look to how Add is implemented, find a map
there, and then look at the function signature, then this makes sense.  What
if all you know about Add is:

  bool NameList::Add (std::string name, Ptr<Object> object);

To me, this is approximately 99.99998% as clear as

  bool NameList::Add (Ptr<Object> object, std::string name);

In both cases I'm adding a bidirectional association between a name and an
object.  I chose the second case since I thought the user view of things was
more important/dominant than the config-side view.  Here a user can just
roughly think of assigning a name to an object.  In this case, the more
typical idiom is assign (to, from).  

It seemed pretty straightforward to me.  But at this point, I've probably
spent more time typing in email about parameter ordering than implementing
the whole NameList patch, examples and tests. :-/

> I was surprised to see in the code that it is just a vector 
> of object/name
> pairs, which is very inneficient for lookup operations.  And 
> lookup will be
> by far the most common operation.

The mapping is bidirectional.  Yes, users probably would only use the method
to find an Object from a name, but I expected to use the reverse map in the
config-side lookup.  This would support situations where, given a config
path segment with aliases -- for example, instead of
"/NodeList/0/devices/1/attr" perhaps something like
"/NodeList/backbone/devices/eth1/attr" or more succinctly
"/backbone/eth1/attr").  But it's not at all clear to me that the underlying
mechanism will remain as simple as even just a bimap, especially given Tom's
requirement for non-unique device names and if we choose to support aliasing
in the NodeList paths (multiple eth1 aliases).

Since I was not 100% clear on what is going to be needed to support the
defined (and partially defined) use cases, and new requirements that are
filtering in, I didn't put any effort whatsoever in optimizing lookups -- I
just put in the basic bimap functionality.  The simplest way to do this was
to do the trivial linear search.  It took a couple of minutes to code.  I
don't expect it to remain that way for all time, of course.  When I have the
thing integrated with the rest of the system, then I'll work on optimizing
it.  It seemed completely pointless to work toward optimizing storage
requirements or lookup efficiency given that I'm not completely sure what
I'll be storing or how it needs to be looked up. :-/

All of this is why there were so many disclaimers in my original email about
the state of the patch and the bug and why I am recommending downgrading the
NameList P1 bug to P2.  The point of most of this discussion is that bug 215
can't really be addressed properly in ns-3.3 and that I want to slip it to
ns-3.4.

Does this not make sense?

[ ... ]