[Ns-developers] Different Approaches to Default Values (was Re: Default Values)

[craigdo@ee.washington.edu]

Hi Mathieu,

[ ... ]

> > The thing that causes the hairs to stand up on my 
> > neck is plumbing the Parameter structures all
> > through the system to get them down to the lower 
> > levels and ensuring they are consistent, not 
> > overwritten unexpectedly, etc., then parsing and 
> > using them in a generic way.
> 
> I have to confess that I do not really understand these generic
> problems. Maybe you could outline briefly in a concrete way 
> the kind of problems you envision.

I looked at the example simple.cc code Tom originally provided:

    Parameters params;
    params.Set ("PointToPoint::ChannelDataRate", "5000000");
    params.Set ("PointToPoint::ChannelDelay", "2");

    Ptr<PointToPointChannel> channel0 =
      PointToPointTopology::AddPointToPointLink ( n0, n2, params);

After putting on my naive user hat, my reaction was astonishment that "they"
(the ns-3 folks) were going to make me do all of that typing and structure
creation just to pass a couple of parameters to a function.  To address the
verbosity, it was suggested that we do,

    Ptr<PointToPointChannel> channel0 =
      PointToPointTopology::AddPointToPointLink ( n0, n2, 
        "PointToPoint::ChannelDataRate", "5000000", 
        "PointToPoint::ChannelDelay" "2");

My reaction (as a new user) was still bogglement.  Why in the world should I
be forced to type some silly class-based parameter name before every
parameter I want to pass in every function call.  C++ provides mechanisms
for default values anyway.  I said to myself then, what is all this crap?

I think both approaches make simple things more difficult to do, which
violates one of Craig's cardinal rules.  I am really turned off by this high
level interface.  (Hmmm. "turned off" is old American hippie slang -- how
about just "unhappy".  Yes.  Okay.  I am very unhappy with this high level
interface.

When I start thinking about putting together these parameter objects and
passing them down into the system, I also wonder about how they are going to
get to where I think they are going.  How do I know that if I make a
Parameters object with some name/value combination and pass it into the
system in a high level interface call, that my parameter name/value
combinations will wander their way down to where I think they will go and
where they will actually be used?  I wonder if there will be a "Parameters
Routing Problem" where I set some local default value and it ends up going
somewhere other than where I think it will; or stops being passed down
before it gets to where I want it to.  How do we enforce this Parameters
passing everywhere?  How do I figure out what happened when my sim doesn't
do what I expected?  How do we explain the routing of Parameters, etc.  This
seems like a hard to understand and debug problem.

Also, since we are all programmers, we naturally think we are smarter than
everyone else :-)  What worries me about this is that "my" Parameters will
get overwritten somewhere down in the stack by someone who "knew better than
me" what that parameter should have been in that case.  We can have rules
about when parameters are allowed to be overwritten, but it seems to me that
lower level code will always have to parse Parameter objects to see if there
is some conflict?  What does this code do if it wants to set a particular
name/value but the name/value is already set in a passed Parameter by higher
level code?  Ignore it?  Overwrite it?  Who decides?  This seems like a hard
to understand and debug problem.

Eventually, when you get down to the lowest level of the code, you are going
to have to take this "data description language" in the form of structures
of parameter objects with associated parameter name/value pairs and
translate that data into the actions of creating some structure of various
kinds of C++ objects with their various member variables set.  This does not
strike me as a particularly trivial task, and we may have to duplicate this
in many places.

So, it seems to me that this Parameters business, if taken all the way to
the end, buys us (I think) lots of complexity and fragility and I'm having a
real hard time justifying that when I think there's a simpler and easier to
understand solution.

Regards,

-- Craig