[Ns-developers] [ns3] topology API
gjcarneiro at gmail.com
Sat Jan 19 04:51:42 PST 2008
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
> like the idea of writing bunches of code every time I do something
> That whole concept drove the idea behind frameworks (and design patterns
> 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
> 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
> 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)
> 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
> be nice if they all worked pretty much the same way (same conceptual
> 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
> you need it are going to work and play well together. I believe there
> 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.
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers