[Ns-developers] Default Values
tomh at tomh.org
Sat Jan 19 06:44:05 PST 2008
Mathieu Lacage wrote:
> On Fri, 2008-01-18 at 21:27 -0500, Joseph Kopena wrote:
>> Hi all,
>> First, a snippet from the Seattle meeting notes:
>> > - Two conventions regarding default values will be adopted:
>> > -- Default values used to set values on an object should, in general,
>> > also have getters and setters to access the value through the
>> > object's interface.
>> > -- Default values may be used for initialization only, and can either
>> > be global, static values or global but changeable per node.
>> 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.
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.
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
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).
>> 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?
More information about the Ns-developers