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

craigdo@ee.washington.edu craigdo at ee.washington.edu
Wed Jan 21 16:03:44 PST 2009

> 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 ...
> 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 ...


-- Craig

More information about the Ns-developers mailing list