[Ns-developers] ns-3-names comments

[Tom Henderson]

Just wanted to add my thoughts on the below thread.

>-----Original Message-----
>From: Gustavo Carneiro [mailto:gjcarneiro at gmail.com]
>Sent: Sunday, February 8, 2009 04:42 AM
>To: craigdo at u.washington.edu
>Cc: 'ns-developers'
>Subject: Re: [Ns-developers] ns-3-names comments
>
>2009/2/8 <craigdo at ee.washington.edu>
>
>> More long email.  But there are reasons that I did what I did and I'm going
>> to explain and justify the design decisions I made ...
>>
>> > 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.

I tend to prefer Find here because of the reasons Craig cited (that it may not be clear to the user whether the object has a name).  That is, it is the way that a user asks the system "does this object have a name yet?"

It may need to be documented more emphatically that all of these Find variants do not assert if there is not a match (they just raise a message at LOG_LOGIC level), and that users should check return values.
 

>> Well, in the Config code, Objects have Attributes and Attributes that have
>> names.  A peath in a config namespace means that there are some number of
>> corresponding Objects that are actually linked together using Attributes.
>> There are rules for what is legal in a path and what correspondences there
>> must be with Attributes.  Path means something that is apparently hard for
>> users to understand.
>
>
>But do you expect "full name" to be easier to explain than "path"?  Paths
>are very intuitive IMHO because we already have encountered in several
>places: file system paths, xml paths (xpath), even ns-3 attribute/config
>paths.
>

Although I don't have the right words handy, I do think that trying to explain it in terms of a path (or maybe as Gustavo suggests, "name path") might be more intuitive.  "full name" doesn't necessarily suggest that a path-like hierarchy is present.

>>
>> I'm not confused or unable to make up my mind.  I deliberately chose to use
>> two method names for what could have been one API method in order to help
>> out two kinds of people operating in very different environments.
>
>
>But why not just pick Find and use C++ overloading here?
>
>Find (context, name)
>Find (fullName)
>
>It makes sense IMHO.  And because of the different arity there is no way C++
>overloading rules are going to screw this up.

I might slightly prefer Gustavo's suggestion here, with a note in the documentation that it could have been named "FindObjectFromFullName" for symmetry, but I can go either way with this point.

----

Mathieu also questioned adding "Rename" method instead of just allowing user to do an "Add" that overwrites the existing name.  The main issue is that Add() will assert if a name already exists.  Another option would be to allow Add() to overwrite without error if a name already exists.

Having a separate method would allow possibly more programming errors to be caught with accidental overwriting.  However, I wonder whether it will lead to code such as the following:

 // I want node0 to be named "accessPoint", regardless of whether it has a name already
 if (Add ("accessPoint", node0) == false)
  {
    if (Rename (Find(node0), "accessPoint") == false)
      {
         NS_ASSERT_MSG ("Cannot add or rename");
      }
  }

rather than the simpler:

if (Add ("accessPoint", node0) == false)
  {
          NS_ASSERT_MSG ("Cannot add or rename");
  }

If we later add an auto-naming capability for objects that can be turned off and on by a global flag, user code will need to be robust to consider both possibilities that a node was either autonamed or not.  In that case, it may be easier to just let Add() provide the renaming capability.

- Tom