[Ns-developers] Default Values

[Gustavo Carneiro]

On 19/01/2008, Tom Henderson <tomh at tomh.org> wrote:
>
> 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.


I think this problem is easy to avoid using a solution like Joseph
proposed.  I would agree except that I would make it slightly more flexible
(more fine grained), but equally safe, in the following manner:

1- Assumption: I assume there is some code, like virtual method, that is
executed when a default value is read;
2- A default value, when it is constructed, starts in a "unlocked" mode;
3- During the unlocked mode a default value can be modified any number of
times;
4- The first time a default value is accessed to read its value then it
switches to a "locked" mode;
5- If the default value is subsequently modified and is in locked mode, an
assertion error is raised and program aborts.

In this method, no explicit locking needs to be done by the programmer; it
is automatic.  And locking is fine grained, per default value.

Also I would very much welcome eliminating DefaultValue classes and replace
them the Parameter and ParamSpec (a DefaultValue then becomes the "initial
value" of some object parameter).  The advantage of this is eliminating one
of the APIs in favour of a more generic one.  The only downside I can see
now is that these new default values have to be associated with some object
class, i.e. they are never any longer "global".  But maybe that is a good
thing.

Regards,

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