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

[Gustavo Carneiro]

On 22/01/2008, craigdo at ee.washington.edu <craigdo at ee.washington.edu> wrote:
>
> [ ... ]
>
> > One thing I wanted to point out before this idea of a 'global' config
> > space goes much further is that it is most likely quite incompatible
> > with the idea that our objects are _dynamically_ aggregated and that
> > they don't know each other. i.e. /nodes/*/tcp/ is a namespace which is
> > created by the user when he aggregates a tcp stack to a set of nodes.
> > So, unless you decide to hardcode somewhere knowledge about the way
> > objects are expected to be aggregated, you won't be able to build the
> > 'global' config namespace or, if you can build it, you won't
> > be able to
> > read from it because objects won't know where they are within this
> > global namespace so they won't be able to read their values
> > from there.
>
> It's not a pretty picture, but I included it just for the sake of
> completeness.
>
> > > Another way to do this is to package this information up into blobs
> > > (Parameters) and pass them down into the system.
>
> [ ... ]
>
> > ok. I think that this 'vector of parameters' can be made to
> > look vastly
> > nicer from a syntactical perspective. But, this is a disgression.
>
> I'm sure we can make it look nicer.  I wasn't particularly worried about
> that yet.
>
> > > Another way is to use a framework approach.
>
> [ ... ]
>
> > Ok. So, in the specific case I outlined, you are suggesting
> > that we ask
> > the user to subclass the HierarchicalMobilityModelFramework
> > to provide a
> > CreateParent and a CreateChild method and that he should pass
> > this class
> > to the topology helper classes ? I am perfectly fine with this: I
> > suspect that this Framework class could be trivially renamed
> > to Factory,
> > hence making its purpose clearer.
>
> Yes.  That is essentially it.  I like the idea of renaming these things
> Factories since framework is a relatively esoteric term.
>
> > What is interesting is
> > that, once you
> > are there, the difference between the Parameter stuff and
> > this explicit
> > base factory class is that the Parameter stuff gives you a data-flow
> > approach to build the factory while what you are proposing is a
> > code-flow approach to build the factory.
>
> Well, I would use the term data-driven instead of data-flow since I'm have
> some roots in computer architecture, and data-flow has a subtly different
> meaning to me; but I understand what you are saying and I think we are on
> the same page.
>
> [ ... ]
>
> > > Unless I am missing something, it [a framework] is much easier to deal
> > with.  But I am
> > > perfectly willing to hear that I have missed something completely.
> >
> > I don't think that the two are fundamentally incompatible: the
> > inversion-of-control is clearly necessary to handle the use-case I
> > described. What I am trying to do with the Parameter proposal is to
> > allow the user a way to easily implement a 'factory' with a data-flow
> > approach. So, the latter approach can be quite naturally
> > built on top of
> > the basic inversion-of-control framework/factory thing.
>
> okay.
>
> > I sense the start of a convergence here. (fingers crossed)
>
> (was that a plus sign or a sign of the cross? :-)
>
> I see the parameters work as it relates to typeinfo as integral to a
> simple
> "local namespace" mechanism reusing the tracing namespace.  I can also see
> how you could use parameters to get configuration information into refined
> framework/factory methods in a reasonable way.  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 suppose it couldn't hurt to have two different kinds of tools available
> here, although one of the big complaints I hear about Windows interfaces
> is
> there are many ways to do pretty much anything in the system and that can
> get confusing and irritating.


Straight from The Zen of Python [1]:

There should be one-- and preferably only one --obvious way to do it.

:-)

[1] http://www.python.org/dev/peps/pep-0020/

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