[Ns-developers] ns-3.4 proposal: Object Name Service

[Gustavo Carneiro]

2009/1/22 <craigdo at ee.washington.edu>

>
> > 1. I'd propose a name/parameter refactoring change like:
> >
> >  - Names::Add (std::string, Ptr<Object>);
> >  + Names::NameObject(Ptr<Object>, std::string)
> >
> > This would follow the verb+object function naming scheme.  I propose
> > that all the "Add" methods are thus renamed and reordered such that
> > the object being named comes first, followed by its name, followed by
> > the context if necessary.
>
> The reason it works the way it does is to allow a conceptual model similar
> to the Attribute system.  This is because the two systems
> (names and attributes) are "unified" in the Config system.
>
> When you think of adding an Attribute, you start with an object to which
> you are adding the attribute; you add an Attribute name,
> and then you set the Attribute to some value.
>
>  object, name, value
>
> Intentionally, I made the calls to Add similar.  You think of an object
> under which you want to add a name entry; you name the
> entry, and then you provide the value (which is an object).
>
>  context, name, object
>
> This ordering is quite intentional to reinforce a shared Attribute/Name
> conceptual model.  I'd need a pretty good reason to do it
> differently ...


Please don't change :-)

I remember the first draft had the API as Add (object, name), which I found
very strange, and tried to convince you to change, unsuccessfully as I
recall.  Glad you arrived at the Add (name, object) conclusion, albeit via
different arguments.

But really, everywhere I see it, this type of data structure is always (key,
value) pairs, never (value, key):

   - std::map<key, value>;
   - python dictionaries;
   - GHashTable (GLib)

I am sure I could find plenty of more examples if I looked, these are just
from memory.


>
>
> > 2. I propose some syntactic sugar, hiding the above API from the user;
> >  essentially, a new Object base class API like
> > Object::AssignName(std::string); this makes things less verbose and
> > leads to changes like:
> >
> > -  Names::Add ("/Names/client", n.Get (0));
> > -  Names::Add ("/Names/server", n.Get (1));
> > +  n.Get (0)->AssignName("/Names/client");
> > +  n.Get (1)->AssignName("/Names/server");
>
> I'm not really sure this buys much and it adds another API "somewhere
> completely different."  I'm willing to consider if there's a
> demand for such things ...


+0.5 for avoiding API duplication.

One small comment I have is, why is the class Names defined in a header file
called object-names.h?  I thought the rules were that the header name would
be the same as the class name, in lower case, words separated by hyphens.

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