[Ns-developers] [ns3] topology API

[Gustavo Carneiro]

On 18/01/2008, craigdo at ee.washington.edu <craigdo at ee.washington.edu> wrote:
>
> > Honestly I don't see the point od TopologyFramework::Build (uint32_t n).
> > It's not like a for-loop is _that_ complex, even in C++.  And I think
> > TopologyFramework::Build just obscures the simple for loop.  And if
> > you start making examples with TopologyFramework::Build then some
> > people will think that TopologyFramework::Build does some kind of
> > special magic to make it happen and will forever be afraid to do a
> > simple for loop.
>
> Well, the whole idea behind topology generation is that the client doesn't
> have to write the for-loop, or the mass of other boiler-plate code that is
> likely going to be in non-simplistic real topology code.
>
> What the Build method hides is all of the grunt work.  I don't
> particularly
> like the idea of writing bunches of code every time I do something
> similar.
> That whole concept drove the idea behind frameworks (and design patterns
> in
> general) in the first place.  I've used frameworks and I can still write
> for-loops.  I've used lots of system libraries and I can still write
> for-loops.  I prefer not to write file systems, whenever possible, though
> :-)
>
> It's hard to illustrate something like a framework with examples simple
> enough to demonstrate their usefulness; just as its hard to illustrate
> something like a library without having something significant enough to
> demonstrate their usefulness.  Perhaps the person who first proposed a
> library heard, "what's with all this linker crap; why don't you just copy
> in
> the code, some people will think that something magic is happening and
> people will forever be afraid to write string comparison functions."
>
> Anyway, you seem to think that a topology framework doesn't do anything
> useful.  From my perspective it does very useful things:
>
> - Provide a simple, consistent, easy to use way for a client to create a
> complex structure of complex objects using a single method call;
> - It allows us to use our simple component substitution mechanisms to
> change
> the complex objects created without programming;
> - It presents a consistent, easy to use model for getting down into the
> depths of the system and allowing us to tweak the control-flow directly
> instead of having to plumb control-flow descriptions (Parameters)
> throughout
> the system.
>
> > I like the idea of container/group much better; at least
> > a container does something useful: keep a list of nodes.
> > I don't think inversion of control is beneficial in this
> > case because it only automates a simple for loop.  And if
> > a new API is not beneficial it ends up being harmful
> > because you have to learn it anyway.
>
> Maybe you could see my point of view better if you thought of a design
> pattern or idiom.  Are design patterns useful?  Are STL queues
> useful?  They
> are often just APIs to automate simple for loops and trivial data
> structures.  Why should you have to learn them?  Well, because they really
> *are* useful.  These things are useful because they are solutions to
> problems that work, have been proven to work, and have most of the grunt
> work done for you.
>
> Just as a design pattern is a generic repeatable solution to a common
> problem, the topology framework is intended to be a generic solution to a
> common topological problem.  Clients don't have to solve the problem over
> and over again.  They just look up the framework that solves their
> particular topology problem and work with it.  Regarding the "frameworks
> considered harmful" view, I have a hard time believing that if you use a
> Singleton design pattern (which is basically just an if statement or a
> static keyword), you'll forget what an if statement is, or what a global
> variable is and how to declare and use them.
>
> The nice thing about design patterns and frameworks is that they are known
> to work (someone has usually put some hard thought into them) and they can
> be reused easily.  If we end up with 50 different stock topologies, it
> would
> be nice if they all worked pretty much the same way (same conceptual
> model)
> and reused as much code as possible.  I wouldn't want to see 50 different
> authors writing 50 different for-loops in slightly different ways with 50
> slightly different ways of calling them.  I especially wouldn't want 50
> different solutions that did the same thing.
>
> By the way, the little bit of pseudocode I provided did use a
> container/group.  That's what it built for you.  The challenge for us will
> be to make sure that the frameworks (generic solutions to the topology
> problems) that also allow you to have access to the innards of the code
> when
> you need it are going to work and play well together.  I believe there
> will
> obviously be more to a framework than a for-loop.


It is certainly possible there might be more than a simple for-loop, but I
think that is unlikely or would be uncommon.  The rule "make common things
simple, uncommon things possible" is broken if you introduce an inversion of
control framework wherein a simple and very common for-loop becomes more
complicated than it has to be.  In contrast, without inversion of control a
for-loop is just a for-loop, nothing fancy, while more complicated node
creation patterns are still possible.

Regards,

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