[Ns-bugs] [Bug 277] star topologies are painful to create

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=277





------- Comment #11 from raj.b at gatech.edu  2008-08-12 12:08 -------
(In reply to comment #10)
> (In reply to comment #9)
> > If any amount of code can be reused easily without copy/paste across multiple
> > source files, it should be done.
> 
> There is, of course, no such black-or-white answer to the problem and your
> comment shows it particularly well. Code reuse has costs. One of them is the
> one you outline below: its does not deal particularly well with variant
> behaviors, hence leading the system to behave in weird ways in some cases. So,
> reusing 5 lines of a trivial for loop must be weighted against allowing
> weird/invalid object/code combinations. I personnally could live with either
> solution but I want to make sure that the consequences of that code reuse are
> clear to everyone.

Yes, there are no black and white answers, only consequences of our design
choices.  The usual line in my defense is that future changes will have to be
made in 3-4 different places IF we change something like behavior or API of
these topology helpers under the copy/paste approach, possibly leading to
subtle inconsitencies.  That and Craig's layering idea under which these stock
topologies are another independent layer on top of the helpers are enough
reason for me to prefer the one solution over the other.

> 
> > The open question in my mind then becomes how do we handle when topology
> > helpers are being used with incompatible device/link types?
> 
> That is clearly one of the issues which must be addressed.
> 

One solution is to make the device and topology helpers into Object subclasses
each with a TypeId, and use aggregation to attach a device helper to a topology
helper.  We then do the inelegant thing: the topology helper iterates GetObject
calls over a list of device helper TypeIds for which it is valid, and if it
gets null after trying all of the "good" types, it gives up and
FATAL_ERROR/ASSERTS out.  The pain of this inelegance is that when new device
types are added, the model author (or people who marshal in the code) have to
add a GetObject check to all of the valid topology helpers.  This seems
somewhat less prone to subtle, non-crashing bugs than the copy/paste approach. 
In the worst case of forgetting to add this check to the topology helpers with
a new device type, the topology helper simply will FATAL_ERROR/ASSERT because
you didn't add the device TypeId as a valid type.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.