[Ns-developers] Default Values

[Mathieu Lacage]

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.

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.

> 
> > 
> >> As I understand it, one of the issues ostensibly being addressed by
> >> limiting default value use to the construction phase is that code may
> >> change values without the user being aware, and cause hard to debug
> >> misbehavior.  However, it's not obvious to me that the factory
> >> getters/setters approach resolves that.  Wouldn't that code just as
> >> easily interact with the factory as change a default value?  It seems
> > 
> > Sure. However, it seems pretty obvious to me that calling a Setter on a
> > factory is not to going to influence in any way the behavior of an
> > object which has already been created by that factory. Or are you
> > referring to another problem ?
> 
> I also fail to see the distinction.  If we establish the above policy on 
> DefaultValue usage, and audit the usage in ns-3-dev to conform to the 
> above guideline, won't that be the same?

In simple cases, yes. However, the example I outlined above shows a case
where it won't be the same.

Mathieu