[Ns-developers] bug 215

[Mathieu Lacage]

hi,

The following bug report generated quite a bit of discussion and
controversy during our last irc meeting so, I would like to try to
summarize the issues and start a discussion in the hope that we can
reach a decision.
http://www.nsnam.org/bugzilla/show_bug.cgi?id=215

1) what is the problem ? The original problem which started this bug
report and, unfortunately does not really appear in this bug report is
the need to identify nodes but also channels by name in simulation
scripts: it is/was felt that using the node indexes in containers or the
global node list is a bit unfriendly. i.e., code such as this:

  ApplicationContainer app = onoff.Install (c0.Get (0));

should instead reference a name:

  ApplicationContainer app = onoff.Install (something ("source"));

2) There are clearly a lot of potential solutions to this problem. Here
is a small list:
  (a) add a SetName/GetName method to the Node class
  (b) add a static SetName/GetName method to the NodeList class
  (c) variant on (a): if no name is set, GetName returns node%i
  (d) add a SetName/GetName method to the Object class
  (e) add a NameContainer class:
class NameContainer
{
  void Set (std::string name, Ptr<Object> obj);
  template <typename T>
  Ptr<T> Get (std::string name);
};
  (f) add a NameList class (or NameList namespace):
class NameList
{
  static void Set (std::string name, Ptr<Object> obj);
  template <typename T>
  static Ptr<T> Get (std::string name);
};

3) There are a number of criteria to look at each solution:
  - scope: assign names to only nodes (a,b,c) or to every object (d,e,f)
  - scope: attempt to help with debugging (c) or not (all others)
  - efficiency: add a std::string to every object (d), to every node
(a,b,c), or only to those who need one.
  - good coherency with existing API (a,d,e) vs bad coherency (b,c,f)

I personally feel that (e) is the way to go because:
  - it allows assigning a name to _every_ object type, not only nodes
  - it solves the original problem, and only that problem (does not try
to deal with debugging as (c)
  - it is pretty efficient (does not require a std::string for every
object or every node when they don't really need it)
  - it fits really well with our container-based helper API (which does
not mean that you have to use the helper API to assign names to objects)

I dislike:
  - (d): objects have no need for names. This is a layering violation
  - (c): trying to solve a problem which no one every really complained
about
  - (a), (b): I really care about being able to set a name on other
objects than nodes.

regards,
Mathieu