[Ns-developers] Default Values

[Tom Henderson]

Mathieu Lacage wrote:
> On Sat, 2008-01-19 at 06:44 -0800, Tom Henderson wrote:
> 
>>>> My take on this was the same as Tom's---that this was talking about
>>>> when objects are created, not necessarily restricting the use of
>>>> default values to scenario construction.  The former seems
>> reasonable
>>>> to me, that default values should only be used to initialize
>> objects
>>>> and should not be referenced throughout its lifetime.  A related
>> point
>>>> is what I was talking about in regard to Craig's Set() function, it
>>>> should be made clear that changing the default values does not
>> effect
>>>> already created objects.  To me that just sounds too chaotic.
>>> What sounds chaotic ? Craig's generic Set ("path", value) proposal
>> was
>>> not related in any way to DefaultValues: it was related to an
>> extension
>>> of the Parameter proposal.
>> Mathieu,
>> I did not read Craig's proposal as an extension to the Parameter 
>> proposal.  I read it as suggesting to set up a parallel configuration 
>> registry that reuses the tracing namespace.
> 
> Hrm. Well, I have a hard time seeing how you could do this without
> integrating the default values into the object itself, which is exactly
> what the Parameter stuff is about. 
> 
>> Can you describe a use case where the above definition:  "Default values 
>> should be only used to initialize objects and should not be referenced 
>> throughout its lifetime" will cause problems?  A use case that does not 
> 
> I do not see any problem with this definition.
> 
>> involve a user abusing or ignoring the above guidance?
>>
>> Another helpful example would be to describe a case where you have a 
>> default value that needs to be overridden during some portion of the 
>> topology phase, and this cannot be accomplished by manipulating the 
>> value of the DefaultValue.  That is what I understand to be a motivation 
>> for your Parameter proposal (to send a configuration object through the 
>> topology API, instead of manipulating a default value).
> 
> If you look a the hierarchical mobility model, you will see that to
> build a hierarchical mobility model, you need to specify a 'parent' and
> a 'child' model. If you use a ClassId for the parent and a separate
> ClassId for the child, you can easily control the _type_ of the object
> to create for each of them when the HierarchicalMobilityModel is
> created. Everything works really well provided the parent and the child
> models are different types of models because they are going to get their
> parameters from different sets of DefaultValues. However, if you want to
> create a child which is the same kind of model as the parent, then, both
> the parent and the child will read their initial values from the same
> set of default values, hence making it impossible to create a child with
> a different set of parameters than the parent unless, of course, you do
> not delegate their creation to the ClassId used by the
> HierarchicalMobilityModel constructor.
> 
> 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.

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?

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.

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 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. 
  That is, I think the underlying problem is that such functions might 
be trying to do too much.

Tom