[Ns-developers] ns-3-names comments

[Gustavo Carneiro]

I was asked to review this ns-3-names code, so here are some thoughts.

  static std::string FindShortName (Ptr<Object> object);
  static std::string FindFullName (Ptr<Object> object);

I think this was already discussed but I'm too lazy to search the archives.

I think I would prefer Get instead of Find here because I associate a "find"
operation as something returning an iterator for the location of something,
and that iterator can be null if the object is not found.  These methods,
however, return always a string (by the way,  the documentation should
indicate that an empty string is returned if the object isn't found).  But
the scenario of returning an empty string is uncommon (I think...), in which
case the Get becomes a stronger alternative to Find.  I would argue that
returning an empty string is uncommon because I don't find it normal for the
programmer to ask for the name of an object if he did not previously had
assigned human readable names to objects of interest.

Another aspect is regarding terminology.  ShortName vs FullName.  Perhaps it
would be simpler to call these just Name and Path?  My ideal naming for
these methods would then be something like this:

  static std::string GetObjectName (Ptr<Object> object);
  static std::string GetObjectPath (Ptr<Object> object);

Idem for FindObjectFromFullName => GetObjectFromPath.

This is just silly:

   * @comment This method is identical to FindObjectFromFullName, but has a
   * short signature since it is a common use and we want it to be easy to
   * type.
   */
  template <typename T>
  static Ptr<T> Find (std::string name);

Make up your mind and choose one method name.   My pick would be to have
just one GetObject (std::string path) method.

  template <typename T>
  static Ptr<T> FindObjectFromShortName (Ptr<Object> context, std::string
name);

I'd also rename this to: GetObject (Ptr<Object> context, std::string name);
C++ overloading will take care of this nicely, and I think this is one case
where overloading does make complete sense.  And instead of 'context'
perhaps just calling the parameter 'parent', or 'parentObject', makes it
easier to understand.

Documentation somewhere says:

   * Given a fullname string, look to see if there's an object in the system
   * with a that associated with it.  If there is, do a QueryObject on the
   * resulting object to convert it to the requested typename.

Of course QueryObject does not exist (sigh), and you mean GetObject.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert