[Ns-developers] Default Values

[Mathieu Lacage]

On Sat, 2008-01-19 at 10:50 -0800, Tom Henderson wrote:

> > If, instead, you can associated to a TypeId a specific set of parameter
> > values to use when creating an object, then, you can make the TypeId of
> > the child have a different set of parameter values than the parent. To
> > achieve this, you need the Parameter stuff.
> 
> It seems like the general problem you are trying to solve is:
> 
>   buildSomeScenario();
> 
> where buildSomeScenario() is some large scenario function that 
> instantiatiates objects of the same type but that must be initialized 
> differently.

Actually, no, this is not the general problem I am trying to solve: the
problem I am trying to solve is:

doSomethingSimpleForMe ()

where the simple thing I am asking for requires creating more than one
object.

For example, the below is not (I think) something which is fundamentally
a "large scenario function":

MobilityHelper helper;
helper.AddHierarchicalMobilityModel (nodeContainer);

But it does suffer from the problem I described, that is, the need to
create n times (where n is the number of nodes) two objects of the same
type in a single function.

> One avenue of solving it is to create an object to pass across the API:
> buildSomeScenario (parameter);
> and have the underlying code be smart enough to parse out this parameter 
> and assign the right values to the right objects.  Is this correct 
> interpretation?

yes.

> 
> Another avenue of solving it is to expose the parameters that are 
> specialized at the API, in the function signature, and have the function 
> explicitly deal with overriding any initialized defaults.
> 
> Another avenue of solving it is to avoid writing the one-shot function 
> "buildSomeScenario()" and instead refactor the scenario code.  For 
> instance, I think what Craig is proposing with frameworks is a way to 
> expose the innards of such a scenario.
> 
> The perception I have of the list discussion so far is that people 
> aren't really looking for large monolithic scenario functions that have 
> these types of problems.  The sentiment seems more oriented towards 
> mid-level helper functions that e.g. create a channel and set of net 
> devices.

Yes. I am not looking into large scenario functions either but the
problem I described happens for much simpler functions unfortunately.

> So some questions I have are whether Parameter is overkill for the 
> problem at hand, or whether some other solution is a better fit, or 
> whether we need to prototype some topology/scenario code before we 
> decide how often this occurs or what are the specific common problems 
> that we are not addressing well.


I certainly think that we should prototype a working solution first
before deciding which way to go. i.e., I am willing to implement a
working Parameter solution together with the associated topology code
even if this code is not merged in the end.


> > I would like to point out that this is really just an example we have
> > today: the fundamental problem is that since you are using a single
> > global variable to hold all the initial values, you cannot instantiate
> > in a single function two objects with different arguments. It works only
> > if you, as a user, are given a chance to change the global value between
> > the two object creations. So far, it sort of works in simple cases but
> > as soon as you get into arranging more complex object structures, you
> > will get in cases like this where multiple objects are created by a
> > single call to a single function from the point of view of the user. You
> > can try to add what craig has been championing to solve this problem,
> > that is, an inversion of control flow but I doubt very much that the
> > result is going to be much easier to deal with.
> 
> I see also some potential difficulty with such large scenario functions 
> and use of Parameter, too, because it seems to me that it will be tricky 
> to make sure that particular parameters are targeted to the right 
> object, and don't miss their mark and instead initialize something else. 

I think that there are 2 problems here:

  - ensure that a parameter is really targetted at a single unique
location. To get this, you need to ensure that parameter names are
unique, potentially by using a prefix, potentially by using the C++
typename of the target object: "ns3::TargetObject::parameterName".

  - know which parameter to use when. One of the goals with the
parameter code is to be able to generate automatically doxygen
documentation which describes precisely which parameters are supported
by which objects.

>   That is, I think the underlying problem is that such functions might 
> be trying to do too much.

I agree that functions which are "large scenario functions" are doing
too much and will lead to many problems. However, this is not the
use-case where I see the problem coming.

regards,
Mathieu