Reusable Components

The current ns-3 codebase has a number of issues with the COM-like framework we have put in place:

Object and Interface

Object is really a very light-weight version of Interface which supports reference counting but not QueryInterface and AddInterface. The current Interface implementation uses quite a few memory resources, even if the object does not support more than one COM interface through QI. As such, a few public objects which needed to support reference counting to uniformize the memory management policy ended up getting Object rather than Interface because Interface was felt to be too heavy.

Furthermore, it happens that the current implementation of the ComponentManager can create only objects which subclass Interface, and not Object. See bug 25.

The obvious solution is to optimize the Interface implementation and use it everywhere in place of Object. Gustavo Carneiro and Mathieu Lacage have worked on this optimization. The result is in http://code.nsnam.org/mathieu/ns-3-devcom in the src/core/interface-object.h/cc files.

This new implementation has a slightly different API when creating new interfaces but it has the exact same API for normal users and avoids extra memory allocations and makes the Ref and Unref operations vastly faster than the default implementation.

The proposal is thus to replace the current Interface and the current Object classes by a single class named Object which would be based on this InterfaceObject code.

Naming-scheme

Part of the reason for the current confusion is that the current codebase does not follow the COM rule that every interface is a pure virtual abstract interface for which multiple implementations can be provided. Our interfaces can and do contain implementation.

The proposal to solve this issue is to accept the fact that our interfaces are not COM interfaces in the sense that they can and they do embed non-pure-virtual methods. To convey this decision more clearly to the user (the fact that we are _not_ COM), the proposal is to remove the I prefixes used in interface names and thus the i- prefix as well as some of the -impl postfix used in interface filenames.

Object creation

The current codebase allows users to do any of:

This is confusing and we need to come up with a decent default behavior. The proposal is to suggest users to use either MakeNewObject Type> or ComponentManager::Create. MakeInternetNode should be removed. calling operator new is still possible but discouraged.

A corollary problem to the use of the ComponentManager is how ClassId instances should be named and where they should be located. We proposal that all global ClassId instances are declared as static const member variables named cid of the object they are expected to create. If that object exports multiple constructors, that object must export multiple ClassId variables: in that case, the ClassId variables should have different names but they should all be prefixed by cid.

In our example, it means that we would have to define the following set of ClassId variables: